对于数据系统表的主键选择不是什么大不了的事,可能对于一些朋友来说,这非常容易,可是却不是如此的简单,对于某些应用来说,自动加1字段就可以了,但是对于某些系统来说,选择自动加1 的方式会带来很大的麻烦,在此种方法的解决上,基本上大多数网友都选择了GUID做为主键,但是选择GUID做为主键的方式有一个缺点:大家都知道GUID是一个128位的整数(32*4),他占用的存诸空间是整数的四倍! 在查询效率方面会不会有很大的影响呢?在这方面,Jimmy Nilsson做了很深的研究(请参见他的著名的文章”The Cost of GUIDS as Primary Keys” http://lists.sqlmagcom/t?ctl=CFBD:83A5C),国内有很多朋友对GUID和comb方式进行了比较,但是大多数是在sql平台上做的,对于GUID字段的支持只有Access和sql 支持,其他的数据库可能并不支持这种方式,所我对这种方式进行了如下的测试.
对于不支持GUID字段的数据库,唯一的方式是对GUID值转化成字符串,也就是说最少需要32*8字节来存GUID(他的转化方式是将GUID的十六进制形式转化为了’0..9’和’A...F’,Base64方法需要更少的存储空间,但是由于BASE64里面即包含大写字每也包含小写字每,所以不适宜表达GUID).我的测试里面包含了四项 1.自动加1字段,2.GUID字符串,3 comb字符串,4.将comb后六个字节放在前面,方便字符串的比较,特别是做主键的时候.
在Jimmy Nilsson The Cost of GUIDS as Primary Keys里对GUID的生成做了详细的说明:
“The algorithm for generating GUIDs doesn’t use the MAC address of the network card in recent Windows versions anymore.Instead ,it just creates a random value.In theory,this presents a risk of getting duplicate GUIDs,but,in practice,it shouldn’t be a problem”
“The reason for excluding the use of the MAC address is that it not only couples users to GUIDs,but some network cards don’t use unique MAC address.”
对于这个情况,Jimmy Nilsson还分别在nt 4+sql 7 和 windows 2000+ sql 2000