请大家说说自已中意的原因
------解决方案--------------------------------------------------------
bigint，速度快
guid，移植性好
一般项目中都用bigint，太灵活就是自找麻烦
------解决方案--------------------------------------------------------
自增型的int ID ，比较常见。
GUID 太长了，查询速度也不如自增型的int ID，除非没办法，我一般不用GUID
------解决方案--------------------------------------------------------
自增型用得多一些.guid感觉效率差点,且太长,存储也会变大.但数据迁移比较方便.
------解决方案--------------------------------------------------------
int型的，guid太长
------解决方案--------------------------------------------------------
都用自己写的Id
------解决方案--------------------------------------------------------
字段大小： GUID： 16字节； int：4字节（范围 0～～2的31次方-1）
表连接： 如果两表关联，如果以自增为主键，先插入到主表获得id，再插入另一表； 若GUID为主键，先生成GUID，然后同时插入
数据库移动： 如果在多数据库中移动数据，以自增为主键的数据需要被修改，从而确保唯一性； 而GUID的就不需要
------解决方案--------------------------------------------------------
以前都用自增，现在都用guid
------解决方案--------------------------------------------------------
ding
------解决方案--------------------------------------------------------
各有优势。上面都分析了。不过我一般用自增列多
------解决方案--------------------------------------------------------
两个都用!!!
------解决方案--------------------------------------------------------
看具体情况，一般用自增型，有时候，当id需要利用程序生成然后再插入记录的话我就会用guid，而且，我认为guid更安全一些，因为如果是自增型的话，别人很容易可以猜到你其他记录的id，这样的话就很容易成批的获取到其他的记录了，guid就可以防止这种情况，你猜不了第二条记录的id是什么！不过，guid的效率当然会低一点拉。。
------解决方案--------------------------------------------------------
guid对数据库中的复制,订阅.可以避免自增型的int ID重复的问题
------解决方案--------------------------------------------------------
都用ID,毕竟项目移植的机会都不大
------解决方案--------------------------------------------------------
这可以看出你的项目的设计者的层次。
假设实例化一个“员工”对象，并且它有一个ID属性用来唯一代表此员工（用姓名、身份证号等任何业务概念都不行，都会要求修改），显然它是GUID型的，因为此时跟数据库完全可以不扯上什么关系。
反过来说，看起来此设计者比较传统、学生气一点。
------解决方案--------------------------------------------------------
另外要说明一下，在SQL Server中，guid是128位二进制数（8个字节），不是什么字符串。虽然SQL Server也可以在T-SQL语句中自动将字符串转换为guid。
------解决方案--------------------------------------------------------
8个字节 --> 8个字(Word)