2009-09-01 158 views
2

當在表(mysql)中建立關係時,我遇到了一個命名困境。外鍵的命名約定

例如,如果我創建一個地方項目可以由多個用戶創建,並通過多個用戶讀取的網站,要鏈接的問題和用戶表,我想可能需要兩個表。

**project_authors** 
questionId 
userId 

**project_bidders** 
questionId 
userId 

這裏的問題是這兩個表的外觀是相同的除外表名。可能是一個更有用的表示是

project_authors 
questionId 
authorId 

project_bidders 
questionId 
bidderID 

在這裏現在的問題是的AuthorID和readerId實際上只是用戶id,並且名稱不反映,並有可能誤導表明, authorId和bidderId是獨一無二的,各有不同。

我相信我的例子有很多孔,但我一直在最近遇到這個問題很多,所以我的問題是你用什麼方法?

+0

請不要說「關係在表格之間「。關係數據庫中的關係是表本身,而不是它們與外鍵之間的關係。有些人對此感到困惑,所以不要進一步混淆它們! – 2009-09-01 14:48:11

+2

約束名可能受到數據庫施加限制的嚴重阻礙,例如, oracle的moronic 30字符標識符限制。 – skaffman 2009-09-01 15:27:34

回答

4

這有什麼錯author_userIDbidder_userID

你有人扮演角色,這總是一個困難的設計。您需要反映角色以及扮演該角色的底層對象。

+0

我認爲他們的問題在於他們長而笨重。我不會調用變量loop_array_index_integer,即使它恰好是循環中用於索引數組的整數! – 2009-09-01 17:11:26

+2

你不會說「loop_array_index_integer」,因爲你沒有一個外鍵的兩個角色。 「loop_array_index_integer」可以毫不含糊地拼寫爲「i」,因爲類型(整數)很明顯。對於數據庫定義,類型(userID)和合格角色(作者或出價者)並不明顯。 – 2009-09-01 18:48:17

3

我會說:

 
project_users 
------------- 
questionId 
userId 
roleId 

其中roleId鏈接到該作者,投標人等積極作用區分表 - 你可以用複合主鍵的選擇控制用戶是否可以只一個(作者投標人)或兩者。前者意味着超過questionId, userId的關鍵,後者是所有三個領域的關鍵。

附註:個人而言,我更喜歡留在一個命名方案。要麼我用everyhing_with_underscores,或者我用camelCase/PascalCase,但不project_usersuserId同一個數據庫中。

+0

好的電話,謝謝你的建議。命名問題仍然存在。例如,如果每個項目只有一個作者,那麼我將它包含在項目表中。 例如 項目 -------- 專案編號 描述 用戶id 是用戶id真是一個正確的名稱,因爲它沒有固有的用戶id是這個項目的作者表示。 – zenna 2009-09-01 14:45:08

+0

我會使用AuthorUserId(我更多地使用SQL Server,其中PascalCase更強大,FWIW)。無論如何,一致性是關鍵。 Sortablity很好,所以UserIdAuthor也是一個選項,取決於你的實踐。無論如何,一個語義上有用的名字總是爲我贏得一個嚴格的名字。 – Tomalak 2009-09-01 14:50:48

0

如果你只是想問一下命名問題,我會使用任何命名方案本身提供的最多文檔。我個人認爲這將是第一個選擇。然而,只要你確定你所做的任何決定都是一致的,並且以某種方式記錄下來,我認爲或者可以正常工作。

但是,您是否想過製作更多表格?也許有users表,其中存儲ID和其他用戶信息,projects表存儲項目,bidders表映射用戶出價項目和authors表將用戶映射到創作的項目?

+0

對不起,也許我沒有說清楚,我有一個用戶和一個項目表。我寫的表格只是按照您的建議執行多對多關係或投標人和作者表。 – zenna 2009-09-01 14:40:37

1

當我可以使用我鏈接到的PK字段的確切名稱。不過,偶爾我可能需要兩個引用在同一個表相同的ID,那麼我會做:

用戶 用戶名

訂單 Customer_UserID SalesRep_UserID

你知道具體使用這樣該ID以及實際的ID名稱。

0

我希望儘可能保持外鍵名稱與主鍵名稱相同。這可以幫助您快速確定列是否是另一個表的外鍵,並且對於它引用哪個表沒有歧義。

tblUser

  • 用戶ID(PK)

tblProjectAuthor

  • ProjectAuthorID(PK)
  • 用戶ID(FK到tblUser)

tblProjectBidder

  • ProjectBidderID(PK)
  • 用戶ID(FK到tblUser)

在您查詢,您可以使用前綴你引用的表的用戶ID來區分。

select author.UserID 
from tblProjectAuthor author 
left join tblUser user on user.UserID = author.UserID 

這個命名方案遇到的唯一問題是當您在同一個表中多次引用外鍵時。一個很好的例子就是一個自我加入的表格。在這樣的情況下,我唯一的建議是用一個有意義的單詞或短語作爲前綴,以幫助區分,同時允許您識別列是外鍵。

例如:

tblEmployee

  • 僱員(PK)
  • ManagerEmployeeID(FK到tblEmployee)
0

我喜歡在我的名字真的很描述性的,因爲更多的時候那麼他們就不會在某些對象上找到代碼作爲屬性名稱。所以你的情況我會

project_authors 
questionId 
authoredByUserId 

project_bidders 
questionId 
bidByUserId 

然後在代碼中訪問它的屬性時,使得很多更有意義,就像

myProjectAuthorEntity.authoredByUserId = someUserId; 
myProjectBidderEntity.bidByUserId = someOtherUserId;