Guid.NewGuid()直接可以生成Guid,不需要通过sql server来生成吧,效率不高。
SqlCommand cmd = New SqlCommand();
cmd.CommandText = "SELECT NewID()";
string rowID = (string) cmd.ExecuteScalar();
cmd.CommandText = "INSERT INTO Table(ID,...) VALUES(@ID,...)
cmd.Parameters.Add("@ID",SqlDbType.UniqueIdentifier).Value = new Guid(rowID);
cmd.ExecuteNoQuery();
但是为什么有人又说
dim GuidID as guid = guid.newguid()
请问为什么我这样生成的GUIDID会有重复值?
这个回复实在是经验之谈:
GUID是很好的主键标识的解决方案,可能有的程序员没有遇见过系统移植,比如以前我做过一个项目,JAVA+SqlServer架构,因一些原因需将之移植到Linux下,得用JAVA+MySQL,而很要命,在SqlServer中用到了自动编号类型的主键,移植中必须将数据导入MySQL,遇上很多的刺手问题,还好数据库的数据还不是很多,用了程序导入,数据库设计总的来说依据3范式,所以必须要程序相应解决了数据的完整性,最后幸不辱使命。
整个移植工作完毕之后,考虑了好多在数据库设计阶段的思路,总结了一些经验。
尽量运用各种常用数据库支持的通用的数据类型,尽量少用或不用自动编号数据库类型;
管理员代号+日期+时间+随机数并不是很好的解决方案,因为同样是损失的索引消耗资源,且程序实现反而不如GUID来得干脆;
不用自动编号字段做主键标识时,尽量少用/不用存储过程根据表中记录的Max(XX)获取当前的最大Int,在你往返查询-->插入数据过程中,时间好象很短,对系统来说已经过了很长时间了,可能你获取了当前应该是100,当你插入数据时,已经又条佬不知什么时候占了100了,这就存在并发的问题;
利用GUID还是解决分布式系统的好方案,在多层分布系统中,多个服务器,多个数据库,如用自动编号,则当你需要汇总数据的时候,会发现麻烦来了,主键重复,系统崩溃。
试验了一下,生成 20000000个guid大概耗时9秒。
Guid.NewGuid();