char,varchar,nvarchar的区别 datetime和smalldatetime的区别 ,这个版比较简单但很实用, char,varchar,nvarchar的区别 平时的ASCII汉字为两个字节 字符串为 dj小溅溅 datetime和smalldatetime的区别 smalldatetime 只能精确到分 ======================================= Varchar 对每个英文(ASCII)字符都占用2个字节,对一个汉字也只占用两个字节
N表示Unicode常量,可以解决多语言字符集之间的转换问题,见联机帮助 姓名,和房间通常都是用varchar这个数据类型 数据库定义到char类型的字段时 char、nchar、varchar、nvarchar、text、ntext中哪一种呢 数据库定义到char类型的字段时,不知道大家是否会犹豫一下,到底选char、nchar、varchar、nvarchar、text、ntext中哪一种呢?结果很可能是两种,一种是节俭人士的选择:最好是用定长的,感觉比变长能省些空间,而且处理起来会快些,无法定长只好选用定长,并且将长度设置尽可能地小;另一种是则是觉得无所谓,尽量用可变类型的,长度尽量放大些。 鉴于现在硬件像萝卜一样便宜的大好形势,纠缠这样的小问题实在是没多大意义,不过如果不弄清它,总觉得对不起劳累过度的CPU和硬盘。 下面开始了(以下说明只针对SqlServer有效): 1、当使用非unicode时慎用以下这种查询: 原因:无法利用到索引,因为数据库会将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类型就这么一点好处。
datetime 和 smalldatetime区别 datetime 从 1753 年 1 月 1 日到 9999 年 12 月 31 日的日期和时间数据,精确到百分之三秒(或 3.33 毫秒)。 smalldatetime 从 1900 年 1 月 1 日到 2079 年 6 月 6 日的日期和时间数据,精确到分钟。 |