※ 引述《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)