設計數據庫時使用表前綴是否是一種好的做法？

設計數據庫時使用表前綴是否是一種好的做法？設計數據庫時使用表前綴是否是一種好的做法？

對於表像，「user_detail」
我使用的列名像ud_name，ud_email等

我這樣做是因爲我想保持唯一的名稱爲每列（每個表），以便稍後在加入時不會遇到列名衝突的問題。

儘管我的一些同事有閱讀列名稱問題（我不知道爲什麼），他們建議名稱應該儘可能簡單和可讀，所以我不應該使用任何前綴。

數據庫設計遵循的標準命名法是什麼？有前綴是不好的？請用一些鏈接支持你的答案。

謝謝
享受制成:)

來源

2011-05-27 Rahul Prasad

過時約定使用表前綴，btw爲什麼你不同意一些模式/約定爲你的數據庫？ – MLS 2011-05-27 10:28:12

請建議一些模式/約定。 – 2011-05-27 11:10:13

如果您有信息... – 2011-06-01 13:28:36

其更好地去與你做

列名像tableprefix_column的東西 - 原因

它使列名唯一和你不要與其他表列名稱發生衝突。
，如果你走了，只是名稱，如列名 - 比你必須要小心的名字，你需要寫tablename.columnname當你寫的查詢，也需要分配別名在查詢欄中像tablename.columnname as xyzname

來源

2011-05-27 10:22:59

表前綴並不是唯一的解決方案，但是當你說數據庫中的列名應該是唯一的時候你是對的！我們的標準與您的標準稍有不同，我們使用表格名稱作爲後綴（見下文），但結果是一樣的：每列都有一個唯一的名稱。對於這個唯一性原則最有價值的論點是視圖和報告：在連接多個表時，您肯定會操縱具有相似含義的列，如'description'，'observation'，'code'或'number'。如果在這個階段，你的專欄名稱相同，你將不得不用別名重命名，使你的觀點混亂，難以理解和維護。

下面是一些我們提供的例子，其中的字段名稱是建出來的性質的數據的（日期，時間，碼號）+的表描述，使得事實上的每一列的面額獨特：

Tbl_Attendance  contains attendance data 
    id_Attendance  is the identifier 
    id_Person   is the foreign key to Tbl_person.id_Person 
    id_Zone   is the foreign key to Tbl_Zone.id_Zone 
    dateAttendance is the attendance date 
    timeInAttendance is the check in time 
    timeOutAttendance is the check out time 

Tbl_PaySlip   contains informations about Payslips 
    id_Payslip  is the identifier 
    id_Person   is the foreign key to Tbl_person.id_Person 
    id_Company  is the foreign key to Tbl_Company.id_Company 
    dateStartPayslip is the starting date of the payslip 
    dateEndPayslip is the ending date of the payslip 
    codePayslip  is the unique code of the payslip, built out from company code, person code, period code

來源

2011-05-27 11:26:54

的問題是相當主觀的，議論......

就個人而言，我倚在不使用前綴和堅持合理名稱的一面。

前綴往往會很快成爲寫作的痛點。當它們看起來有用時，我發現最好將表格，列或兩者都相應地進行別名，即：

select ud.name as ud_name, 
     ud.email as ud_email 
from user_detail as ud;

而且，我從來沒有處理/配置中使用的ORM應用程序的上下文DB前綴，但是，如果有的話，我想這是不是很漂亮。

來源

2011-05-27 11:27:17

這是一個類似的對話，整個「匈牙利符號」的辯論 - http://en.wikipedia.org/wiki/Hungarian_notation。

不管你做什麼，我都建議你的整個團隊使用相同的約定來命名你的數據庫實體 - 即使是你不同意的標準。

我喜歡http://www.interaktonline.com/support/articles/details/Design+Your+Database-Database+Naming+Convention.html?id_art=24&id_asc=221作爲標準。

來源

2011-05-27 11:51:04

+1，請接受答案。「無論您做什麼，我都建議您的整個團隊使用相同的約定來命名您的數據庫實體 - 即使使用了您不同意的標準。」 – 2011-06-01 20:08:12

幾張海報，包括標誌性的海報，都吹捧了獨特的專欄名稱的好處，好像它是一種自然而明顯的先天優點。我問：爲什麼列名中的唯一性很好？四十年前，有大型機數據存儲技術需要唯一的列名稱。這污染了二十年前PC上dBase的設計和更多。由於佔統治地位的數據存儲模型已經成爲關係數據庫管理系統，所以我沒有要求，也沒有理由要求唯一的列名稱。

有一個被稱爲「域名完整性」的概念，它僅僅意味着沒有它的包含表的上下文，列名是沒有意義的，就像表名沒有它自己的模式和數據庫的上下文無意義一樣。

您不能引用列而不引用其在SQL中的包含表。如果您認爲表格名稱太長，並且您不想一直輸入，則可以將其用於您的選擇列表。

如果使用通過干擾表名稱或表名稱的縮寫形成列名稱的唯一列名稱，這與使用表名（或縮寫別名）代替你的前綴有下劃線？我認爲事實並非如此。不同之處在於，將父指示符強制爲子名稱只會使該子名稱的可讀性降低，並且不可避免地會導致更多的冗餘和不可讀的SQL。

我在SQL Mag論壇上討論了我的首選命名約定this post。

最好的名字是清楚地描述它們包含的數據的內容或含義的最短自然名稱。這些名稱可以並且必須在包含它們的對象的上下文中進行。嘗試強加獨特性或使用其他格式（如Hungarianizing表和列）會增加混亂，這會使數據庫難以閱讀和理解，從而使您的系統不易受支持。

來源

2011-05-29 11:30:12

（Zombification alert！）原則上，使列和表名儘可能短是有意義的。但是，這種方法存在兩個實際問題。第一個問題是編輯在理解代碼方面的能力有限。假設你有兩個不同的列名稱「id」，並且你想搜索你的（比如說PHP）代碼來獲得特定表的id。我知道的所有編輯都會無法辨別您想要搜索哪張表的ID。如果您在1個數據庫中填充多於1個模式，則不爲表添加前綴也可能成爲問題。（例如：custom + phpbb3）。 – Agamemnus 2014-02-03 16:34:52

設計數據庫時使用表前綴是否是一種好的做法？

回答

相關問題