原因不知道，在线等答案，转帖的就算了，要的是经验，麻烦把原理 show 出来 ，谢
16 个解决方案
#1
因为它是Unicode数据，编码格式和其它的不一样，
另外SQL Server 的未来版本中将删除 ntext、text 和 image 数据类型
#2
2005 建议存储大数据或二进制数据推荐使用nvarchar(max)、varchar(max) 和 varbinary(max)
#3
个人经验，建议将ntext在etl过程中转化为nvarchar，我一次在sql server中处理ntext出现不合事实的结果
#4
一楼： ntext 是Unicode 多语言的编码格式， varchar char 等又是什么编码格式，为什么 多语言的Unicode 编码就不能添加其他约束？
#5
什么约束？ntext、image 不能用作主键列，因为他们不能被索引。
#6
check 约束
#7
default 可以吧？ primary key 、unique 约束肯定不行了
#8
alter table tableName
add constraint CK_tableName_columnName check (columnName not like '''')
提示不能创建约束 这里的columnName 列为 ntext 类型
add constraint CK_tableName_columnName check (columnName not like '''')
提示不能创建约束 这里的columnName 列为 ntext 类型
#9
感谢楼上楼下的各位热心帮助
关键是 现在 ntext 类型 只有not null 约束 其他的约束好像都不行 ，这我知道 问题是到底为什么 原理是怎样的不知道
关键是 现在 ntext 类型 只有not null 约束 其他的约束好像都不行 ，这我知道 问题是到底为什么 原理是怎样的不知道
#10
貌似不能吧
#11
因为不能在他们上面建立索引，所以不能有primary key 、unique 约束
至于check 不明白，我基本上没用过ntext 期待高手回答
#12
肯定不了 要是可以 我就不发上来了
#13
9 楼说的明白了一点
还剩下一个check 约束
我等等等等等等等等等等等等。。。
还剩下一个check 约束
我等等等等等等等等等等等等。。。
#14
找到一段博文 大家分享
数据库定义到char类型的字段时 char、nchar、varchar、nvarchar、text、ntext中哪一种呢 数据库定义到char类型的字段时，不知道大家是否会犹豫一下，到底选char、nchar、varchar、nvarchar、text、ntext中哪一种呢？结果很可能是两种，一种是节俭人士的选择：最好是用定长的，感觉比变长能省些空间，而且处理起来会快些，无法定长只好选用定长，并且将长度设置尽可能地小；另一种是则是觉得无所谓，尽量用可变类型的，长度尽量放大些。
鉴于现在硬件像萝卜一样便宜的大好形势，纠缠这样的小问题实在是没多大意义，不过如果不弄清它，总觉得对不起劳累过度的CPU和硬盘。
下面开始了(以下说明只针对SqlServer有效)：
1、当使用非unicode时慎用以下这种查询：
select f from t where f = N'xx'
原因：无法利用到索引，因为数据库会将f先转换到unicode再和N'xx'比较
2、char 和相同长度的varchar处理速度差不多（后面还有说明）
3、varchar的长度不会影响处理速度！！！（看后面解释）
4、索引中列总长度最多支持总为900字节，所以长度大于900的varchar、char和大于450的nvarchar,nchar将无法创建索引
5、text、ntext上是无法创建索引的
6、O/R Mapping中对应实体的属性类型一般是以string居多，用char[]的非常少，所以如果按mapping的合理性来说，可变长度的类型更加吻合
7、一般基础资料表中的name在实际查询中基本上全部是使用like '%xx%'这种方式，而这种方式是无法利用索引的，所以如果对于此种字段，索引建了也白建
8、其它一些像remark的字段则是根本不需要查询的，所以不需要索引
9、varchar的存放和string是一样原理的，即length {block}这种方式，所以varchar的长度和它实际占用空间是无关的
10、对于固定长度的字段，是需要额外空间来存放NULL标识的，所以如果一个char字段中出现非常多的NULL，那么很不幸，你的占用空间比没有NULL的大（但这个大并不是大太多，因为NULL标识是用bit存放的，可是如果你一行中只有你一个NULL需要标识，那么你就白白浪费1byte空间了，罪过罪过！），这时候，你可以使用特殊标识来存放，如：'NV'
11、同上，所以对于这种NULL查询，索引是无法生效的，假如你使用了NULL标识替代的话，那么恭喜你，你可以利用到索引了
12、char和varchar的比较成本是一样的，现在关键就看它们的索引查找的成本了，因为查找策略都一样，因此应该比较谁占用空间小。在存放相同数量的字符情况下，如果数量小，那么char占用长度是小于varchar的，但如果数量稍大，则varchar完全可能小于char，而且要看实际填充数值的充实度，比如说varchar(3)和char(3)，那么理论上应该是char快了，但如果是char(10)和varchar(10)，充实度只有30%的情况下，理论上就应该是varchar快了。因为varchar需要额外空间存放块长度，所以只要length(1-fillfactor)大于这个存放空间（好像是2字节)，那么它就会比相同长度的char快了。
13、nvarchar比varchar要慢上一些，而且对于非unicode字符它会占用双倍的空间，那么这么一种类型推出来是为什么呢？对，就是为了国际化，对于unicode类型的数据，排序规则对它们是不起作用的，而非unicode字符在处理不同语言的数据时，必须指定排序规则才能正常工作，所以n类型就这么一点好处。
数据库定义到char类型的字段时 char、nchar、varchar、nvarchar、text、ntext中哪一种呢 数据库定义到char类型的字段时，不知道大家是否会犹豫一下，到底选char、nchar、varchar、nvarchar、text、ntext中哪一种呢？结果很可能是两种，一种是节俭人士的选择：最好是用定长的，感觉比变长能省些空间，而且处理起来会快些，无法定长只好选用定长，并且将长度设置尽可能地小；另一种是则是觉得无所谓，尽量用可变类型的，长度尽量放大些。
鉴于现在硬件像萝卜一样便宜的大好形势，纠缠这样的小问题实在是没多大意义，不过如果不弄清它，总觉得对不起劳累过度的CPU和硬盘。
下面开始了(以下说明只针对SqlServer有效)：
1、当使用非unicode时慎用以下这种查询：
select f from t where f = N'xx'
原因：无法利用到索引，因为数据库会将f先转换到unicode再和N'xx'比较
2、char 和相同长度的varchar处理速度差不多（后面还有说明）
3、varchar的长度不会影响处理速度！！！（看后面解释）
4、索引中列总长度最多支持总为900字节，所以长度大于900的varchar、char和大于450的nvarchar,nchar将无法创建索引
5、text、ntext上是无法创建索引的
6、O/R Mapping中对应实体的属性类型一般是以string居多，用char[]的非常少，所以如果按mapping的合理性来说，可变长度的类型更加吻合
7、一般基础资料表中的name在实际查询中基本上全部是使用like '%xx%'这种方式，而这种方式是无法利用索引的，所以如果对于此种字段，索引建了也白建
8、其它一些像remark的字段则是根本不需要查询的，所以不需要索引
9、varchar的存放和string是一样原理的，即length {block}这种方式，所以varchar的长度和它实际占用空间是无关的
10、对于固定长度的字段，是需要额外空间来存放NULL标识的，所以如果一个char字段中出现非常多的NULL，那么很不幸，你的占用空间比没有NULL的大（但这个大并不是大太多，因为NULL标识是用bit存放的，可是如果你一行中只有你一个NULL需要标识，那么你就白白浪费1byte空间了，罪过罪过！），这时候，你可以使用特殊标识来存放，如：'NV'
11、同上，所以对于这种NULL查询，索引是无法生效的，假如你使用了NULL标识替代的话，那么恭喜你，你可以利用到索引了
12、char和varchar的比较成本是一样的，现在关键就看它们的索引查找的成本了，因为查找策略都一样，因此应该比较谁占用空间小。在存放相同数量的字符情况下，如果数量小，那么char占用长度是小于varchar的，但如果数量稍大，则varchar完全可能小于char，而且要看实际填充数值的充实度，比如说varchar(3)和char(3)，那么理论上应该是char快了，但如果是char(10)和varchar(10)，充实度只有30%的情况下，理论上就应该是varchar快了。因为varchar需要额外空间存放块长度，所以只要length(1-fillfactor)大于这个存放空间（好像是2字节)，那么它就会比相同长度的char快了。
13、nvarchar比varchar要慢上一些，而且对于非unicode字符它会占用双倍的空间，那么这么一种类型推出来是为什么呢？对，就是为了国际化，对于unicode类型的数据，排序规则对它们是不起作用的，而非unicode字符在处理不同语言的数据时，必须指定排序规则才能正常工作，所以n类型就这么一点好处。
#15
顶！
#16
没彻底解决 还是结贴吧
感谢各位关注
感谢各位关注
#1
因为它是Unicode数据，编码格式和其它的不一样，
另外SQL Server 的未来版本中将删除 ntext、text 和 image 数据类型
#2
2005 建议存储大数据或二进制数据推荐使用nvarchar(max)、varchar(max) 和 varbinary(max)
#3
个人经验，建议将ntext在etl过程中转化为nvarchar，我一次在sql server中处理ntext出现不合事实的结果
#4
一楼： ntext 是Unicode 多语言的编码格式， varchar char 等又是什么编码格式，为什么 多语言的Unicode 编码就不能添加其他约束？
#5
什么约束？ntext、image 不能用作主键列，因为他们不能被索引。
#6
check 约束
#7
default 可以吧？ primary key 、unique 约束肯定不行了
#8
alter table tableName
add constraint CK_tableName_columnName check (columnName not like '''')
提示不能创建约束 这里的columnName 列为 ntext 类型
add constraint CK_tableName_columnName check (columnName not like '''')
提示不能创建约束 这里的columnName 列为 ntext 类型
#9
感谢楼上楼下的各位热心帮助
关键是 现在 ntext 类型 只有not null 约束 其他的约束好像都不行 ，这我知道 问题是到底为什么 原理是怎样的不知道
关键是 现在 ntext 类型 只有not null 约束 其他的约束好像都不行 ，这我知道 问题是到底为什么 原理是怎样的不知道
#10
貌似不能吧
#11
因为不能在他们上面建立索引，所以不能有primary key 、unique 约束
至于check 不明白，我基本上没用过ntext 期待高手回答
#12
肯定不了 要是可以 我就不发上来了
#13
9 楼说的明白了一点
还剩下一个check 约束
我等等等等等等等等等等等等。。。
还剩下一个check 约束
我等等等等等等等等等等等等。。。
#14
找到一段博文 大家分享
数据库定义到char类型的字段时 char、nchar、varchar、nvarchar、text、ntext中哪一种呢 数据库定义到char类型的字段时，不知道大家是否会犹豫一下，到底选char、nchar、varchar、nvarchar、text、ntext中哪一种呢？结果很可能是两种，一种是节俭人士的选择：最好是用定长的，感觉比变长能省些空间，而且处理起来会快些，无法定长只好选用定长，并且将长度设置尽可能地小；另一种是则是觉得无所谓，尽量用可变类型的，长度尽量放大些。
鉴于现在硬件像萝卜一样便宜的大好形势，纠缠这样的小问题实在是没多大意义，不过如果不弄清它，总觉得对不起劳累过度的CPU和硬盘。
下面开始了(以下说明只针对SqlServer有效)：
1、当使用非unicode时慎用以下这种查询：
select f from t where f = N'xx'
原因：无法利用到索引，因为数据库会将f先转换到unicode再和N'xx'比较
2、char 和相同长度的varchar处理速度差不多（后面还有说明）
3、varchar的长度不会影响处理速度！！！（看后面解释）
4、索引中列总长度最多支持总为900字节，所以长度大于900的varchar、char和大于450的nvarchar,nchar将无法创建索引
5、text、ntext上是无法创建索引的
6、O/R Mapping中对应实体的属性类型一般是以string居多，用char[]的非常少，所以如果按mapping的合理性来说，可变长度的类型更加吻合
7、一般基础资料表中的name在实际查询中基本上全部是使用like '%xx%'这种方式，而这种方式是无法利用索引的，所以如果对于此种字段，索引建了也白建
8、其它一些像remark的字段则是根本不需要查询的，所以不需要索引
9、varchar的存放和string是一样原理的，即length {block}这种方式，所以varchar的长度和它实际占用空间是无关的
10、对于固定长度的字段，是需要额外空间来存放NULL标识的，所以如果一个char字段中出现非常多的NULL，那么很不幸，你的占用空间比没有NULL的大（但这个大并不是大太多，因为NULL标识是用bit存放的，可是如果你一行中只有你一个NULL需要标识，那么你就白白浪费1byte空间了，罪过罪过！），这时候，你可以使用特殊标识来存放，如：'NV'
11、同上，所以对于这种NULL查询，索引是无法生效的，假如你使用了NULL标识替代的话，那么恭喜你，你可以利用到索引了
12、char和varchar的比较成本是一样的，现在关键就看它们的索引查找的成本了，因为查找策略都一样，因此应该比较谁占用空间小。在存放相同数量的字符情况下，如果数量小，那么char占用长度是小于varchar的，但如果数量稍大，则varchar完全可能小于char，而且要看实际填充数值的充实度，比如说varchar(3)和char(3)，那么理论上应该是char快了，但如果是char(10)和varchar(10)，充实度只有30%的情况下，理论上就应该是varchar快了。因为varchar需要额外空间存放块长度，所以只要length(1-fillfactor)大于这个存放空间（好像是2字节)，那么它就会比相同长度的char快了。
13、nvarchar比varchar要慢上一些，而且对于非unicode字符它会占用双倍的空间，那么这么一种类型推出来是为什么呢？对，就是为了国际化，对于unicode类型的数据，排序规则对它们是不起作用的，而非unicode字符在处理不同语言的数据时，必须指定排序规则才能正常工作，所以n类型就这么一点好处。
数据库定义到char类型的字段时 char、nchar、varchar、nvarchar、text、ntext中哪一种呢 数据库定义到char类型的字段时，不知道大家是否会犹豫一下，到底选char、nchar、varchar、nvarchar、text、ntext中哪一种呢？结果很可能是两种，一种是节俭人士的选择：最好是用定长的，感觉比变长能省些空间，而且处理起来会快些，无法定长只好选用定长，并且将长度设置尽可能地小；另一种是则是觉得无所谓，尽量用可变类型的，长度尽量放大些。
鉴于现在硬件像萝卜一样便宜的大好形势，纠缠这样的小问题实在是没多大意义，不过如果不弄清它，总觉得对不起劳累过度的CPU和硬盘。
下面开始了(以下说明只针对SqlServer有效)：
1、当使用非unicode时慎用以下这种查询：
select f from t where f = N'xx'
原因：无法利用到索引，因为数据库会将f先转换到unicode再和N'xx'比较
2、char 和相同长度的varchar处理速度差不多（后面还有说明）
3、varchar的长度不会影响处理速度！！！（看后面解释）
4、索引中列总长度最多支持总为900字节，所以长度大于900的varchar、char和大于450的nvarchar,nchar将无法创建索引
5、text、ntext上是无法创建索引的
6、O/R Mapping中对应实体的属性类型一般是以string居多，用char[]的非常少，所以如果按mapping的合理性来说，可变长度的类型更加吻合
7、一般基础资料表中的name在实际查询中基本上全部是使用like '%xx%'这种方式，而这种方式是无法利用索引的，所以如果对于此种字段，索引建了也白建
8、其它一些像remark的字段则是根本不需要查询的，所以不需要索引
9、varchar的存放和string是一样原理的，即length {block}这种方式，所以varchar的长度和它实际占用空间是无关的
10、对于固定长度的字段，是需要额外空间来存放NULL标识的，所以如果一个char字段中出现非常多的NULL，那么很不幸，你的占用空间比没有NULL的大（但这个大并不是大太多，因为NULL标识是用bit存放的，可是如果你一行中只有你一个NULL需要标识，那么你就白白浪费1byte空间了，罪过罪过！），这时候，你可以使用特殊标识来存放，如：'NV'
11、同上，所以对于这种NULL查询，索引是无法生效的，假如你使用了NULL标识替代的话，那么恭喜你，你可以利用到索引了
12、char和varchar的比较成本是一样的，现在关键就看它们的索引查找的成本了，因为查找策略都一样，因此应该比较谁占用空间小。在存放相同数量的字符情况下，如果数量小，那么char占用长度是小于varchar的，但如果数量稍大，则varchar完全可能小于char，而且要看实际填充数值的充实度，比如说varchar(3)和char(3)，那么理论上应该是char快了，但如果是char(10)和varchar(10)，充实度只有30%的情况下，理论上就应该是varchar快了。因为varchar需要额外空间存放块长度，所以只要length(1-fillfactor)大于这个存放空间（好像是2字节)，那么它就会比相同长度的char快了。
13、nvarchar比varchar要慢上一些，而且对于非unicode字符它会占用双倍的空间，那么这么一种类型推出来是为什么呢？对，就是为了国际化，对于unicode类型的数据，排序规则对它们是不起作用的，而非unicode字符在处理不同语言的数据时，必须指定排序规则才能正常工作，所以n类型就这么一点好处。
#15
顶！
#16
没彻底解决 还是结贴吧
感谢各位关注
感谢各位关注