在列名中包含子字元串“_id”
我有一個團隊表。每個
Team人都有一個 ID。我有另一張桌子，裡面有玩家。每個人都
Player被分配到一個團隊。所以我的桌子可能看起來像
CREATE TABLE players ( id INTEGER PRIMARY KEY name STRING team_id INTEGER REFERENCES teams(id) ) CREATE TABLE teams ( id INTEGER PRIMARY KEY name STRING )寫作是否
_id更清楚地表明該列用於保存團隊的 ID（而不是團隊名稱）？如果我看到它
team連結到teams表上的一個鍵，我會假設該列用於保存一個 ID。我發現，如果我開始遵循一個我加入的對流，我
_id最終會得到很多列_id，但我不確定它是否增加了任何價值。
這是一個風格問題，並且可能會變得宗教化。就個人而言，我確實發現明確標記 ID 欄位
TeamID和PlayerID; 正如您所說，它非常清楚該欄位儲存的是 ID 而不是其他類型的數據，例如標籤。從長遠來看，明確通常比簡短更有價值。我更喜歡使用
PlayerID,TeamID等ID而不是 ，但是我不能隨便給你一個令人信服的理由。這意味著您的聯接始終是 X 到 X (P.TeamID = T.TeamID)，而P.ID和T.ID是非常不同的欄位，不應加入。在瀏覽查詢時，它比andP.ID更容易混淆。另一方面，始終為您的 PK 使用相同的欄位名稱也很有價值。T.ID``P.PlayerID``T.TeamID
您談到在 Players Team 中命名該列而不是 Team_Id，並且您很容易看出它與 Team.Id 相關。是的，你可以弄清楚。是的，這很容易。如果您有外鍵可以幫助您。如果您在創建任何查詢之前檢查外鍵。而且，如果您沒有外鍵並且在 Team 表中碰巧沒有相同數據類型的另一列，請說 Team.TaxId 或類似的東西。在我的腦海裡有很多如果。
為了使程式碼更易於閱讀和更易於維護，您可以做的一件事是使用一致的命名標準。這意味著，如果您要通過列 Team 引用 Team.Id，請確保您在整個數據庫中始終如一地執行此操作。Players.Id 將始終與 TableName.Players 等相關聯。如果您這樣做並記錄它，那麼您應該沒有任何問題。使用 Team.TeamId、Player.PlayerId、Player.TeamId 等的好處是它是一個通用的命名標準，如果您的公司有大量的 DBA 變更，下一組正在查看您的程式碼的人將是更容易理解它。