GUID 与　自增型的int ID 你会中意那个多一点？
请大家说说自已中意的原因

------解决方案--------------------
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)