[討論] 複合主鍵(Composite Primary Key)

看板Soft_Job作者 (Gary)時間9年前 (2015/05/27 23:15), 9年前編輯推噓5(5011)
留言16則, 8人參與, 最新討論串1/1
之前的專案經驗,DB的PK大多是複合主鍵,不愛用流水編號, 主要是流水編號是沒有意義,所以盡量都是以欄位來當PK。 但最近專案在玩新技術,有些觀念似乎有點模糊,框架官網 表明ORM不支援複合式主鍵Table,建議使用Uniqe來代替複合式主鍵, 框架的觀念在於PK應該是唯一的,不該是靠幾個欄位來達成資料的唯一性, 如果有此需求,應該是以Unique來達成。 想請問各位的專案,PK都怎麼建? 有常用複合式主鍵嗎?哪種觀念才是對的? 另外,各位常用Foregin Key嗎,因為玩ORM發現他對ORM很重要, 但以往的專案很少用這個東西(主要是User要求刪資料的時候很麻煩) 跟各位請益 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.232.120.146 ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1432739727.A.92A.html ※ 編輯: MacPerson (36.232.120.146), 05/27/2015 23:17:40

05/27 23:18, , 1F
為什麼你認為流水編號沒意義?int欄位拿來當pk效率不是
05/27 23:18, 1F

05/27 23:18, , 2F
比較好嗎?
05/27 23:18, 2F
有效率但不好維護,不夠直觀,而且與User溝通,他不懂什麼是流水編號, 他只會拿它們觀念上的PK跟PG溝通,例如身分證號或名字+手機之類 但這是我的經驗,也希望大家能夠討論,讓我學習

05/27 23:26, , 3F
我知道很多case都會是複合,但我習慣都會給一個int當pk
05/27 23:26, 3F

05/27 23:26, , 4F
所以就有兩種pk這樣,遇到效能問題就能用int pk解決
05/27 23:26, 4F

05/27 23:26, , 5F
跟user說當然是以他們懂得複合來說 只是在table join
05/27 23:26, 5F

05/27 23:27, , 6F
要很小心就是了
05/27 23:27, 6F
※ 編輯: MacPerson (36.232.120.146), 05/27/2015 23:49:46

05/28 00:26, , 7F
我反而覺得流水號很方便耶XD
05/28 00:26, 7F

05/28 01:46, , 8F
使用者用身分證跟PG溝通 關PK什麼事情?
05/28 01:46, 8F

05/28 01:47, , 9F
你知道身分證是一個欄位 PK是流水號不就好了嗎
05/28 01:47, 9F

05/28 09:26, , 10F
為什麼ORM會不支援複合主鍵?我想並非所有ORM都如此
05/28 09:26, 10F

05/28 12:53, , 11F
GUID當key 可以解決你的問題吧!
05/28 12:53, 11F

05/28 14:41, , 12F
把兩個有意義的東西放在一起當PK是很蠢的想法…等你要出一
05/28 14:41, 12F

05/28 14:41, , 13F
堆報表時 你就知道惹!
05/28 14:41, 13F

05/28 19:30, , 14F
用GUID取代INT作為PRIMARY KEY是更好的解法,GARTNER
05/28 19:30, 14F

05/28 19:30, , 15F
第一象限的CRM軟體都是採取這一類的作法。
05/28 19:30, 15F

05/29 07:50, , 16F
你之前專案的資料量可能不大
05/29 07:50, 16F
文章代碼(AID): #1LPT-Fag (Soft_Job)