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

[MacPerson (Gary)]

之前的專案經驗，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
推 sing10407: 為什麼你認為流水編號沒意義？int欄位拿來當pk效率不是
→ sing10407: 比較好嗎？
有效率但不好維護,不夠直觀，而且與User溝通，他不懂什麼是流水編號，
他只會拿它們觀念上的PK跟PG溝通，例如身分證號或名字+手機之類
但這是我的經驗，也希望大家能夠討論，讓我學習
推 sing10407: 我知道很多case都會是複合,但我習慣都會給一個int當pk
→ sing10407: 所以就有兩種pk這樣,遇到效能問題就能用int pk解決
→ sing10407: 跟user說當然是以他們懂得複合來說 只是在table join
→ sing10407: 要很小心就是了
※ 編輯: MacPerson (36.232.120.146), 05/27/2015 23:49:46
推 yyc1217: 我反而覺得流水號很方便耶XD
→ GoalBased: 使用者用身分證跟PG溝通 關PK什麼事情?
→ GoalBased: 你知道身分證是一個欄位 PK是流水號不就好了嗎
推 psliurt: 為什麼ORM會不支援複合主鍵?我想並非所有ORM都如此
推 teemocogs:  GUID當key 可以解決你的問題吧！
→ pooznn: 把兩個有意義的東西放在一起當PK是很蠢的想法…等你要出一
→ pooznn: 堆報表時 你就知道惹!
→ cellochou: 用GUID取代INT作為PRIMARY KEY是更好的解法，GARTNER
→ cellochou: 第一象限的CRM軟體都是採取這一類的作法。
→ ChungLi5566: 你之前專案的資料量可能不大