為什麼人們建議不要將名稱“Id”用於標識列？
我被教導不要在
Id我的表的標識列中使用名稱，但最近我一直在使用它，因為它簡單、簡短，並且非常能描述數據的實際內容。我見過有人建議在
Id表名前加上前綴，但這似乎為編寫 SQL 查詢的人（或者如果你使用像實體框架這樣的 ORM 的程序員）做更多的工作，特別是在較長的表名上，例如CustomerProductId要麼AgencyGroupAssignementId我們聘請的一位第三方供應商為我們創建了一些東西，實際上命名了他們所有的身份列
Ident，只是為了避免使用Id. 起初我以為他們這樣做是因為Id是關鍵字，但當我查看它時，我發現這Id不是我們正在使用的 SQL Server 2005 中的關鍵字。那麼為什麼人們建議不要將名稱
Id用於標識列呢？**編輯：**為了澄清，我不是在問要使用哪種命名約定，也不是在詢問使用一種命名約定而不是另一種命名約定的參數。我只是想知道為什麼不建議使用
Id標識列名稱。我是一個程序員，而不是 dba，對我來說，數據庫只是一個儲存數據的地方。由於我通常建構小型應用程序，並且通常使用 ORM 進行數據訪問，因此標識欄位的通用欄位名稱更易於使用。我想知道這樣做我錯過了什麼，以及是否有任何真正好的理由讓我不這樣做。
表名前綴有很好的理由。
考慮：
TableA (id int identity, stringdata varchar(max)) TableB (id int identity, stringdata varchar(max))我們希望
DELETE從TableA兩個表中都存在的記錄中提取。很簡單，我們將只做一個INNER JOIN：DELETE a FROM TableA A INNER JOIN TableB B ON b.id = B.id….我們剛剛消滅了所有
TableA. 我們無意中將 B 的 ID 與自身進行了比較——每條記錄都匹配，每條記錄都被刪除。如果欄位已命名
TableAId，TableBId這將是不可能的 (Invalid field name TableAid in TableB)。就個人而言，我對
id在表中使用名稱沒有任何問題，但是用表名（或實體名稱，如果TableA人們PeopleId也可以正常工作）作為前綴確實是一種更好的做法，以避免意外比較錯誤的欄位並吹有事。
JOIN這也使得在具有大量s的長查詢中欄位來自何處變得非常明顯。
主要是為了防止外鍵成為巨大的痛苦。假設您有兩個表：Customer 和 CustomerAddress。兩者的主鍵都是名為 id 的列，它是一個標識 (int) 列。
現在您需要從 CustomerAddress 引用客戶 ID。顯然，您無法命名列 id，因此您使用 customer_id。
這導致了幾個問題。首先，您必須始終記住何時將列稱為“id”，何時將其稱為“customer_id”。如果你把它搞砸了，它會導致第二個問題。如果您有一個包含十幾個連接的大型查詢，並且它沒有返回任何數據，請玩 Where’s Waldo 並找出這個錯字：
ON c.id = ca.id哎呀，應該是
ON c.id = ca.customer_id。或者更好的是，描述性地命名您的身份列，因此它可以是ON c.customer_id = ca.customer_id. 然後，如果您不小心在某處使用了錯誤的表別名，customer_id 將不會成為該表中的列，並且您將得到一個很好的編譯錯誤，而不是空結果和隨後的程式碼瞇眼。當然，在某些情況下這無濟於事，例如，如果您需要從一個表到另一個表的多個外鍵關係，但將所有主鍵命名為“id”也無濟於事。