表列名稱設計

假設我有以下表格：Customer和Staff。表列名稱設計

Customer (CusID, CusName, CusAddres, CusGender) 
Staff (StaID, StaName, StaAddress, StaGender)

Customer(ID, Name, Address, Gender) 
Staff(ID, Name, Address, Gender)

哪個設計更好呢？

來源

2012-08-01 Edwin

我會親自挑＃2 - 它有很少冗餘和不必要的重複。如果你使用'Customer.ID'，已經清楚你正在處理一個客戶 - 不需要在'CusID'列名中重複這個... – 2012-08-01 10:02:17

我強烈建議**不要**使用MixedCase。 SQL本身默認情況下不區分大小寫，但DBMS實現可以改變它。如果你堅持使用小寫字母（也可能是下劃線），遷移到另一個平臺將不那麼痛苦。另外：避免保留字，關鍵字和類型名（日期，名稱），甚至包括其他平臺的名稱。 – wildplasser 2012-08-01 10:10:46

SQL採用一種稱爲域名完整性這意味着對象的名稱具有由其容器給予的範圍的概念。

列名必須是唯一的，但僅限於包含列的表的上下文中。表名必須是唯一的，但僅限於包含表的模式的上下文中，等等。

當您查詢列時，您需要引用您感興趣的模式，表和列，除非有一個或多個這些可以推斷出來。除非您的查詢非常簡單，只能引用一個表，否則您需要直接引用表名或使用別名引用表名。來自客戶C的Customer.ID或C.ID等

第一個選項是對所有列名的唯一性的技術要求的回退，它適用於舊的ISAM數據庫和20世紀60年代的COBOL等語言， 20世紀70年代。這在20世紀80年代被毫無理由地拖入了dBase中，並且在關係和對象DBMS時代已經成爲一種慣例。 抵制這個過時的慣例。

第二種方法更簡單，更具可讀性。更簡單，更易讀的代碼更容易編寫，並且更容易維護。

來源

2012-08-01 13:09:20

每個行業都有自己的標準。在那些設計風格都是正常的。建議使用第一個。

Customer(CusID, CusName, CusAddres, CusGender) 
Staff(StaID, StaName, StaAddress, StaGender)

因爲它使用表名符號像Customer到Cus和Staff到Sta。它有助於該項目良好的維護。

某些組織也正在使用vch爲VARCHAR數據類型，int爲INT數據類型。

像

Customer(intCusID, vchCusName, vchCusAddres, vchCusGender) 
Staff(intStaID, vchStaName, vchStaAddress, vchStaGender)

來源

2012-08-01 10:06:33

我個人不喜歡這個。我認爲絕對不需要在每個領域重複實體名稱。在查詢中，您通常會在字段名前使用表名。除非你只有一張桌子，但是重複兩次都沒有意義。 – 2012-08-01 15:26:21

Thnx隊友。也許你是對的。但是，我們正在使用這樣的字段名稱，而且我們的數據庫大多數都有超過100個。的表格。 – 2012-08-02 06:42:55

我要說的是，第二個選項是更好的。如果您決定更改表名稱，則不必更改所有列的名稱。同樣，當你編寫你的SELECT語句時，你通常還是使用別名（「select sta.name，sta.adress from staff sta ...」）一般來說，如果有疑問，總是選擇一個更簡單的解決方案。

來源

2012-08-01 10:12:57 rmaruszewski

謝謝大家的幫助:) – Edwin 2012-08-02 03:48:04

鍵被「傳播」到外鍵上，所以如果他們的名字在所有的「副本」中保持不變，那麼它很有用。它只是使數據庫模式更清晰：您不必查看FK定義以查看特定字段的來源 - 您可以通過查看其名稱來完成此操作。

另一方面，非關鍵字段不會傳播，並且沒有特別的理由使它們的名稱在它們各自的表格外保持唯一。

所以，我推薦一種混合的方法：

前綴鍵字段名，讓他們所有表中是唯一的，避免任何需要重命名傳播領域。
不要在非關鍵字段名稱前面加上短名稱，儘管這可能會導致不同表格中的名稱重複。

例如：

Customer (CustomerID, Name, Addres, Gender) 
Staff (StaffID, Name, Address, Gender)

如果你碰巧有兩個之間的結合表，它會看起來像這樣...

CustomerStaff(CustomerID PK FK1, StaffID PK FK2)

.. .so不需要重命名（如果兩個父鍵都被命名爲ID，這將是必要的），並立即清除CustomerID和StaffID來自哪裏。另外，我個人不喜歡縮短前綴中的表名（因此CustomerID而不是CusID），因爲這使得命名更「機械」且可預測。

他們潛在的多層次！

只是一個例子。是否有道理是另一回事。

來源

2012-08-01 15:19:10

除了個人喜好之外，沒有什麼特別的理由要有一個命名約定，即外鍵字段的名稱應該等於主鍵字段的名稱。實際上，經常發生的情況是，一個表可能有多個外鍵指向同一父表，所以有時需要在外鍵名和主鍵名之間存在差異。有些人認爲，主鍵名稱前面帶有表示_harms_可讀性的前綴，而不是相反。 – 2012-08-01 18:16:42

@JoelBrown正如我在我的回答中解釋的那樣，除了個人偏好之外，還有一個原因：通過讀取其名稱，立即知道特定移植密鑰來自何處的能力。至於同一父母的多個FK，這當然不會經常發生（我能想到的一個常見情況是實施DAG），即使它存在一致的重命名方案，以保留名稱的「精神」它仍然清楚它來自哪裏。至於那些「相信前綴......有害可讀性」的人，我希望他們解釋_why_？ – 2012-08-01 19:41:18

@BrankoDimitrijevic順便說一句，NATURAL JOIN和JOIN ... USING可以從相同的名字中受益。 – 2012-08-01 19:46:46

ID是一個SQL反模式（http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?s=books &即= UTF8 & QID = 1343835938 & sr = 1-1 & keywords = sql + antipatterns），從不命名列ID。我會用：

Customer(CustomerID, Name, Address, Gender) 
Staff(StaffID, Name, Address, Gender)

來源

2012-08-01 15:46:00 HLGEM

「ID」是否是SQL反模式是宗教戰爭的問題。迷戀自然聯結的人認爲ID是一種反模式。另一方面，也有其他人認爲自然聯結是懶惰和草率的，並且是自身的反模式。 – 2012-08-01 18:08:15

我不使用自然連接（SQL Server不允許它們，我也不會，因爲我同意它是不好的技術）儘管如此，它是固有的你保護你的數據庫通過不使用保證會導致問題的技術，如果一些後來的人在路上確實使用自然連接。這是基本的設計，從不創造太容易被濫用的東西。我也知道這是一個反模式，因爲我編寫複雜的報表查詢，它也會產生問題。 – HLGEM 2012-08-01 18:36:39

我還注意到，我有一位頂級SQl專家寫的一篇參考文章，也稱之爲反模式。 – HLGEM 2012-08-01 18:39:48

表列名稱設計

回答

相關問題