讨论有关GUID的优劣

公司新项目,主键都采用的GUID类型,请各位高手发表一下自己的看法。
[34 byte] By [soaringsouth-栈桥捉鳖] at [2008-1-9]
# 2
SQL中有这个数据类型么?
# 3
问下楼主:栈桥捉鳖 ?是深圳的么?

80405046??
lovcal-枫兮 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 4
SQL Server中好像没有GUID类型吧
glacier111-★冰河★ at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 5
lovcal(枫兮) ( ) 是谁?
soaringsouth-栈桥捉鳖 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 6
80405046是不是你的QQ?
lovcal-枫兮 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 7
GUID与Identity的优缺点:
前者是全球唯一的,如果同一个Table在多个DB,或者在多个Server中存在,而到了某个时候这些相同Schema的Table中的数据要合并到一起,这个时候GUID的优势就体现出来了。这些数据的ID绝对不会发生重复。

[bookonline]中的描述
自动编号和标识符列
对任何表都可创建包含系统所生成序号值的一个标识符列,该序号值唯一标识表中的一行。例如,当在表中插入行时,标识符列可自动为应用程序产生唯一的客户收据号码。标识符列在其所定义的表中包含的数值通常是唯一的。这意味着在包含标识符列的其它表中可使用与之相同的数值进行标识。但是,由于标识符值通常是在一个独立表的上下文中使用而不与其它表中的标识符列发生关联,所以通常不会发生问题。

可在每个表上创建一个全局唯一标识符列,而该列中包含对世界上所有网络计算机均不重复的值。当必须对来自多个数据库系统的相似数据进行合并时(例如,在包含位于世界各地分公司的数据的客户帐单系统中),包含全局唯一值的列很有用。当数据汇集到中心进行合并和制作报表时,使用全局唯一值可防止不同国家/地区的客户拥有相同的帐单号或客户 ID。

Microsoft® SQL Server™ 2000 在合并复制中使用全局唯一标识符列,以确保在表的多个复本间唯一标识行。

如果没有前文所述的那种需求发生,不建议使用GUID,它的性能比int类型的identity差很多。
bugchen888-臭虫 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 8
同意,使用GUID当主键除非有必要,一般来说不推荐

想想在一堆乱七八糟的数据上作索引,性能较差的

而一般的情况下,主键当索引使用得较多
lovcal-枫兮 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 9
personal
# 10
进来学习.
# 11
如果没有复制,尽量不要采用GUID,GUID主要是解决数据合并时行唯一定位的,因为这样的列的值没有什么规律,所以很难对其优化.
hellowork-一两清风 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 12
guid固然好哈
不过我觉得太长了
不容易记忆
查询起来也似乎不怎么好
基本上不用它的
还使用identity的好
有必要的时候采用guid
比如说数据库里面就着一样东西
全局唯一的时候
# 13
整形的identity占的空间小,索引搜索时也快,
CrazyFor-冬眠的鼹鼠 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 14
当然GUID有性能有一定的影响!
比如做主从式表时,主表的主键是要做为从表的外键。如果主表主键是Identity类型字段就不能返回一个值啊。
skyclin at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 15
当然GUID有性能有一定的影响!
比如做主从式表时,主表的主键是要做为从表的外键。如果主表主键是Identity类型字段就不能返回一个值啊。
skyclin at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 16
当然GUID有性能有一定的影响!
比如做主从式表时,主表的主键是要做为从表的外键。如果主表主键是Identity类型字段就不能返回一个值啊。
skyclin at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 17
我数据中的每行记录都有GUID,但绝对不会用来做主键,
THXK-THXK at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 18
尽量用Identity,没有办法采用guid,我们一般用自定义主键
# 19
是否可以再立一个Identity,但只做索引不做主键呢?
# 20
使用GUID作为数据表主键的好处

数据表主健通常采用以下三种方式:

1. 自动递增值。

2. 唯一名称。这个是使用自己定义的算法来生成一个唯一序列号。

3. GUID(全局唯一标识符)。

GUID与自动递增值及唯一名称比较
GUID
在客户端生成,由GUID的特性决定,通过GUID生成的值可能出现重复的机会几乎等于零,因此保证在插入表的时候主键值唯一。

可以方便处理分布式数据的提交,比如:分店数据向总店提交――直接将该部分数据插入即可。

支持离线数据处理。对本地数据包进行新增记录时即可将该数据表的关键字段值赋值,其处理方法是与在线新增时是一致的。

自动递增值
在数据库服务器端生成,由于该值是由数据库系统内部处理的,亦保证其唯一性,但由于其是在数据库服务器端生成,因此必须将该值返回客户端,客户端通过该值过行其它操作。比如一张单据(主从表)是使用自动递增值,当插入单据抬头后,必须将单据抬头的关键字段值返回,再插入单据明细(单据明细是通过单据抬头关键字段进行关联的)。

不能很好处理分布式数据的提交,比如:分店数据向总店提交――提交数据时必须重新生成该数据表的关键字段值,以保证该字段值唯一。

要支持离线数据处理需要进行额外的处理,对本地数据包进行保存记录(保存到本地)时需要插入一个假设唯一值,在提交离线数据回数据服务器时再重新生成真正的唯一值,并重新进行相关的处理。

唯一名称
在客户端生成或在服务端生成,相对于自动递增值不同的地方就是自己维护生成唯一值的算法及所保存的临时值,容易造成出错或其它问题。如果是在客户端生成唯一值的话,还必须保证所生成的值是唯一的。

不能很好处理分布式数据的提交,比如:分店数据向总店提交――提交数据时必须重新生成(或预先处理)该数据表的关键字段值,以保证该字段值唯一

要支持离线数据处理需要进行额外的处理,对本地数据包进行保存记录(保存到本地)时需要插入一个假设唯一值,在提交离线数据回数据服务器时再重新生成真正的唯一值,并重新进行相关的处理。

参考:
http://dev.Codefund.cn/article/60/60007.shtm
chanfengsr-巉沨散人 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 21
Guid好啊,我一直用它.
Lovedog404 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 22
好处大大的。
缺点是占用空间多,性能低。
在这两者都不是问题的情况下,推荐用之
# 23
反对一刀切,比较傻X
xthmpro_cn-[可人] at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 24
不涉及数据库之间的合并就不要用,只有涉及到的表才采用,就这么简单
emilchan6k-emilchan at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 25
如果日后有数据同步需求,可以考虑使用guid,这个东西是全球唯一的,但是要考虑到业务数据的唯一性,06年我做过一个项目,access数据汇总到sql server中,使用到了guid,效果不错,但是遇到一个客户的硬盘损坏,业务数据全部重新录入,这时会产生的guid值和以前上传到sql server中的guid不一样的情况。
# 26
使用GUID的话一般还要附带一个Datetime类型的字段。
# 27
GUID几乎没有用过,一般都是用identity,占用空间很小。
wf5360308-冷月孤峰 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 28
GUID 在并发性上好于identity
但是空间引索就不如identity了
呵呵
kkk3k3k at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 29
GUID合并数据方便,但效率、存储空间、可读性堪忧。
identity效率较高、空间小,合并数据麻烦些。
# 30
不建议这样做
zzzl-不拉拉链 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 31
看应用了.

我用 GUID, 因为我是做三层应用, 要处理主从表时,不用先得到主表的ID, 而直接从客户端生成, 一次性提交到服务器就OK了.
fox1999-红狐 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 32
個人建議使用identity
marco08-天道酬勤 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 33
用guid做主键,主要是程序里面获得方便,identity不易获得,但对索引实在没有什么好处,每次插入不规则的guid,索引维护开销很大
# 34
看应用了.

我用也是 GUID, 因为我是做三层应用, 要处理主从表时,不用先得到主表的ID, 而直接从客户端生成, 一次性提交到服务器就OK了.

GUID可以在客户端生成ID,这一点比较好!至于索引个人认为可以另开列!
99414325ALe-抵制日货 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 35
反对楼上若干星星们关于GUID对索引没有好处的发言。

大家都混淆了真实的GUID(java里面叫UUID)的概念。GUID并不就是指随机生成码。那个只是类似NewID()函数或者java.util.UUID.randomUUID()返回的128-bit随机数,而这只是GUID/UUID很多种生成方式变种中的一种。

see http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt

我们完全用同时结合id或者其他序列号生成方式、以及系统IP、启动时间等信息的方式,在服务器程序端、甚至数据库端生成一套连续、但是全球唯一的ID,充分利用GUID的优势,进而兼顾将来可能的数据合并,同时又不会引起大的更新索引开销的方式。

当然,一般的系统还是强烈建议直接使用id。

=======
回复人:fish_yht(百行孝为先,万业勤为径) ( ) 信誉:100 2007-1-1 0:16:21 得分:0

guid固然好哈
不过我觉得太长了
不容易记忆
========

这个不是用来给人看的,是唯一确定一条记录的
shine333-enihs at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 36
个人观点
1。GUID的最大好处,在分布式数据库作数据合并时不会出现相同值
2。由于GUID的长度过大,其实如果作pK的话,可能引起INSERT语句的缓慢
iacpdj-dj at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 37
一般用uniqueidentifier字段(.NET中叫Guid结构)
在编程时可以省去不少麻烦,用作PK不会重复
关于索引,可以加一个Default GETDATE()的Datetime列即可

不知各位为什么要用identity列,用作序号?
仅仅是为了好记?
不知道为Microsoft为什么要提供identity列
# 38
我们项目是用guid做的.插入的时候确实慢!
性能和方便性看你取舍了
# 39
自增长列非常适用于web开发,通过一个数据表中不重复的id就能找到要修改的字段。比用复合主键传值方便。
moonshineidolon-神 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 40
谁有Gmail 的邀请函,我的邮箱是wodxtl@21cn.com
wodxtl at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 41
分析数据的时候你会后悔的。
yuanmu-原木 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 42
除了没有任何意义的数据,不要用GUID
yuanmu-原木 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 43
不错! 收藏!
move_forward at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 44
数据太大了不用guid用什么?long也有限制呀...int才2亿多..
aspDB用的就是这个,看看别人怎么用的..
zheng616-猪八戒 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 45
上海的一个大公司用的也是GUID型的,偶的代码一些参考他的,NND 做主从表对数据的时候眼睛都看花了
kaper3 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 46
学习ing
nedvedlh-shirley at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 47

太麻烦了吧, 能不用就不用.
integer不好吗? 单独为表加入一个与内容毫无关系的内容, 显然不太值得.

DanielWYO-爱上小白 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 48
我大部分表都是用 GUID 做主健的。

很好用。
# 49
回复人:DanielWYO(爱上小白) ( ) 信誉:100 2007-1-5 8:28:24 得分:0

?

太麻烦了吧, 能不用就不用.
integer不好吗? 单独为表加入一个与内容毫无关系的内容, 显然不太值得.

==================================
正好相反,姑且不论用GUID还是其他什么ID,但是在很多实际情况中,在表中加入一个和业务毫无关系,只是用来唯一确定一条记录的字段,非常值得。
shine333-enihs at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 50
建议用int,
guid一般情况不用,我宁可用时间戳
sp4-1 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 51
我反正是两个都用,第张表中都有递增的identity和GUID

GUID在操作时只有在新建数据的时候由程序而不是数据库生成。将SQL提交后通过GUID查出ID。
修改,删除,检索,主从表关联时都是用ID做为标识。
ZyxIp-绝望中... at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 52
学习中,又了解不少知识!
# 53
我也用Guid :)
# 54
甚至为了防止重复,Guid后面再加了一个机器名,哧哧
# 55
to whmjw(明年今日十年之后)
不如加上自己的个性签名
zzzl-不拉拉链 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 56
在有些情况下两个都用,通常在一些基础信息表中可以用GUID和有意义的ID,该ID作为PK,GUID作为备用的,这样用ID和GUID都可以查询
ttjacky-豆豆糖 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 57
wodxtl@21cn.com,给你发了,请查收~
SZ31654270-魔幻天空 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 58
长知识,顶
ziyuan_1016 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 59
GUID数据导入导出时也很有好处
# 60
注意:每张表都必需有个和业务逻辑无关字段作为唯一标识

采用guid无疑是很不错的

alicc-狂图 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 61
都说GUID的索引性能不佳,有没有具体的benchmark说明啊?
skyswan-施望 at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...
# 62
guid关联多表的时候速度比用int慢的好多,但是比int好的就是数据的唯一性比较好,要是经常进行数据组合,导入,用guid维护比较好维护!
zsl5305256-快乐就好! at 2007-10-18 > top of Msdn China Tech,MS-SQL Server,基础类...