我有一種情況，我想知道使用 table_id 還是只使用 id 是否更常見？（在我看來，使用 table_ 會導致稍微混淆它是否是外鍵）。人們更喜歡哪個，兩者之間真的有什么區別嗎？還是應該只選擇一個并保持一致？
uj5u.com熱心網友回復：
就表格中的列命名而言，主要有兩種趨勢：
模式命名空間
該策略是 70 年代記錄資料庫“資料字典”的團隊構想的傳統策略。這個想法是列的名稱本身告訴您它屬于整個架構或資料庫中的哪個表。例如，CLIENT_NAME將代表CLIENT表中客戶的名稱。
這種策略有一些變體，其中有限數量的字母被分配為前綴（特別是對于 M:N 關系表），因為當時在許多資料庫中列名被限制為 6 或 8 個字符。例如，客戶購買汽車的日期可以采用CLI_CAR_DATE、CLICAR_DATE或什至 的形式CLCADT。
例子：
- 物體表“car”的主鍵“id”列將命名為
CAR_ID。 - 指向“汽車”的子表“檔案”上的外鍵將采用相同的形式：
CAR_ID. 這允許使用自然連接；但是，應該指出的是，有令人信服的理由不惜一切代價避免自然連接，這里不討論。 - 與“人”有多個（兩個）關系（賣方和買方）的表“轉移”上的外鍵污染了這種策略。它們可以命名為：
PERSON_BUYER_ID并且PERSON_SELLER_ID因為兩者不能具有相同的名稱PERSON_ID；它不再允許自然連接（好）。
表命名空間
在此策略（即較新的）中，列名不包括它們所屬物體的名稱，而僅包括它們的屬性名稱。這種策略更符合物件設計，并產生更短的名稱（即更少的打字）。提及列時必須注明表名。例如，您需要說出NAMEtable 上的列CLIENT。
例子：
- 物體表“car”的主鍵“id”列將命名為
ID。 - 指向“汽車”的子表“檔案”上的外鍵將采用以下形式
CAR_ID：這與之前的策略是相同的解決方案。 - 與“人”有多個（兩個）關系（賣方和買方）的表“轉移”上的外鍵可以命名為：
BUYER_ID和SELLER_ID. 他們可以按照之前的策略使用較長的名稱，但這里的目標通常是使用較短的名稱，以便應用程式源代碼更容易撰寫和除錯。
概括
我個人喜歡第二個，但有些團隊同時堅持這兩種策略并且沒有明顯的贏家。我傾向于第二個是 [我認為] 第一個遭受更長的名稱（更多鍵入）、更長的 SQL（更多錯誤）、神秘的名稱（它們不能很好地與 ORM 和應用程式物件配合使用）以及外鍵不能很好地遵循策略。事實上，我的資料庫中幾乎所有的主鍵都是命名ID的，而不管具體的物體是什么。
But on the flip side, some teams value very highly the idea of knowing the table name of a column by just looking at it. And this is great for big databases (with 200-1000 relational fact tables) that can become quite complex, specially for new members of a team.
But above all, pick one and be consistent.
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/446373.html
上一篇：想要搜索兩個表PythonSQL