※ 引述《flakchen (flak)》之铭言： : ※ 引述《jameswiki (乌龟(弄论文中..))》之铭言： <前面吃光光了..太长了XD> Well,蛮多人讨论的..呵， 用guid,newid()来产生值做为PK的目的很多, 其实这种用Guid来做PK键的讨论很多, 是否合用,见人见智, flack大大,您资料表上千万上亿笔的,或许不合用, 不过换成小弟,但在初始规划时,我大概不会规划这种一次存上亿笔的, 不用比那个小小的字串跟整数当PK的效能, 光是left join一次上亿笔就吃不消了 可能我经验不足,不过若100万笔资料来做连几次left join, 前台的client大概都不要用了,上亿笔?..我不敢想... (不要跟我说所有栏位都在同一table,你从来不用left join,那又要讨论资料库规划 -->离题了XD) 那麽,如果你都可以忍受上亿笔去做left join, EX:A表1亿笔,B表1亿笔,c表5千万笔, select xxx as result from A left join b on a.xx1=b.xx2 left join c on a.xx2=c.xx3 where a.xx5='xxxx' union select yyy as result from D left join e on D.xx1=e.xx2 left join f on D.xx2=f.xx1 union : : <连续10个union> 等个5-10分把资料抓出来,或者不要用union,可能只要一个left join就要等很久了 为什麽无法忍受guid用来当PK 跟用整数当PK ,所影响的那点效能? 小弟我懒得打字,关於类似这种Guid使用的好坏, 我引述下面网址的文章 http://blog.miniasp.com/post/2008/01/08/The-Gospel-of-the-GUID.aspx 其实我自己用久了,发现其实好处不止如此了..不一一列举,就以这份文章讨论吧 ===================================== 为什麽要使用GUID的四大理由： 1. I can make less trips to the database, now THAT is a performance enhancement! 你可以直接在Application中直接产生GUID，不用进资料库执行 NEWID() 函数 2. Data Merging is so easy, Mac using developers can do it! 在不同的应用程式之间产生的资料或两台资料库之间，很容易就可以合并资料到同一 个表格。 3. Type/Table Ignorance 要做资料稽核的纪录，或各个表格资料加上一个Note栏位等应用，都很适合用GUID处 理，但别想让这个表格去查Parent Row这件事，很没意义！ 4. The hits just keep on coming! 很容易区分哪些是「测试机上的资料」或「正式机上面的资料」，直接拿测试机的 GUID去删除正式机上相同的GUID即可！ 两个使用 GUID 的缺点： 1. 比较难自己手动下SQL取得资料 SELECT * FROM ORDER WHERE ORDERID = 12 比以下这个 SQL 好下多了: SELECT * FROM ORDER WHERE ORDERGUID = ‘ {45F57B42-38A4-46ce-A180-6DE0E7051178}' 2. 在效能上，用 GUID 一定比用 INT 栏位格式，但只有慢一点点而已，几乎没理由不用 ！ ====================================================================== 关於这份链结,所推出来的四个链结,在该网址後方,大家可以去参考讨论一下。 都是一些原文对Guid的讨论及使用 当然,使用Guid 用久会有缺点,所以要去设定填满因子或每一段时间跑维护 话说回来,这个版是个好地方cc..,有不少高手可以一起讨论这些~赞啦~ ※ 编辑: jameswiki 来自: 220.142.205.153 (03/19 00:08)