使用表名稱的前綴命名錶的列想法還是不好？

下面是兩個具有不同列命名約定的相同表，哪一個更好，爲什麼？使用表名稱的前綴命名錶的列想法還是不好？

<<User>> 
id 
name 
age

<<User>> 
user_id 
user_name 
user_age

一個明顯的優勢，我看到的是，當涉及到連接兩個不同的表的表相同的列名可以得到重疊，如果不是以「AS」正確別名。但是後者沒有這樣的需求，但我仍然發現許多使用第一種結構的項目？這是爲什麼？

來源

2011-09-04 Mr Coder

它不是唯一的答案，但我這是怎麼建立DB結構：

表名是大寫和複數：Users，Documents，Products
列名是小寫
主鍵包含以單數形式的表格前綴：user_id,document_id
外鍵與它們所指的主鍵具有相同的名稱

因此，例如，在用戶和文件的情況下：

Users     Documents 
--------    ---------- 
user_id PK ----.  document_id PK 
nickname  `----- user_id FK 
hash     title 
         content

在這些表中選擇的所有文檔標題與暱稱用戶=「wintermute」你可以這樣寫：

SELECT 
    Documents.title AS title 
FROM Documents 
    LEFT JOIN Users USING(user_id) 
WHERE nickname = 'wintermute'

來源

2011-09-04 12:31:20

根據SQL標準（和大多數DBMS），'Documents'，'documents'，'DOCUMENTS'是相同的標識符。 –

@a_horse_with_no_name，所以我想你沒有意識到在MySQL中（在windows上而不是在nix上）表名是區分大小寫的。所以....作爲主題有標籤[標籤：MySQL]我認爲這是相關的。 –

是的，我知道這個（非標準的）事實。實際上，在Windows上，MySQL（與MyISAM）在默認情況下不區分大小寫，因爲文件系統不是。在Unix/Linux上它是區分大小寫的，因爲文件系統是區分大小寫的 –

這風格從Oracle黑客昔日來到時dinasours統治地球。 請勿使用它。這是痛苦和醜陋的。我強烈勸阻這種做法。

來源

2011-09-04 02:17:33 regality

在最近的數據庫設計課上，我的講師鼓勵前綴約定。它看起來很糟糕。

來源

2011-09-04 02:19:59

我們使用了類似的約定作爲第一個例子在工作中，在我們的Oracle盒，坦率地說我恨它。

對我來說，我認爲這是大量的冗餘; 但我確實接受，在大型查詢中它可以幫助調試，它非常明顯。

哪一個更好？沒有好的答案;哪一個讓你感覺不那麼糟糕！這是唯一真實的答案。

來源

2011-09-04 02:21:52

我覺得我個人比較喜歡

<<User>> 
    id 
    name 
    age

我想是因爲SELECT user.id, user.name FROM user是完美的閱讀和理解。我從過於詳細的user.user_id看不到太多好處。另外，在編寫面向對象的代碼時，我們不會調用用戶對象的id user_id，爲什麼在數據庫中呢？

A clear advantage I see is when it comes to joining tables same column name 
of two different tables can get overlap if not aliased properly with 'AS'

我明白你的意思，但寫這

SELECT user_id FROM user 
INNER JOIN account ON account.account_id = user.account_id

任何優於

SELECT user.id FROM user 
INNER JOIN account ON account.id = user.account_id

在第一個例子，如果賬戶表中也有一個user_id領域，我們仍然要前綴SELECT user_id FROM...與SELECT user.user_id FROM...

據我所見第二個例子是多好些。

來源

2011-09-04 08:56:39 MrMisterMan

我同意。但我認爲他意味着一點點不同的事情。例如：'select * from t1 join t2 on t1.id = t2.id'。在這種情況下，如果列名未加前綴，星號將返回兩個不明確的ID。所以在你的情況下，查詢中需要別名。但無論如何，我認爲使用別名比使用前綴更好。 – Karolis

@Karolis'select *'從來不是一個好主意（除了嘗試，調試等） –

我個人不使用前綴。不適用於列和不適用於表格（tblSomething只是一個荒謬的名字）。

一個例外，但（總是有一個，不是嗎？）是ID列。

儘管所有其他列名通常與表本身強關聯，並且可以很容易地在沒有前綴的SQL語句中發現，但ID列是不同的。

所以我發現自己經常使用的東西，如：USER_ID，名字，姓氏

來源

2011-09-04 09:12:32

如果你在一個帶連接的select中做多個'tablename。*'，你最終會得到多個'id'列（來自不同的表），這是令人困惑的，所以將表名添加到主鍵是一個好主意。就個人而言，我不是'user_id'，而是簡單地使用'user'。例如，「加入評論（users.user = comments.user）」。 – OdraEncoded

複雜的系統經常使用元數據存儲庫。元數據存儲庫要求數據元素是唯一的。因此，例如，具有相同數據元素名稱（id）的147個表格，但具有不同數據定義（用戶ID，帳戶ID等）將不起作用。

從這個角度來看，「user_id」的「user」部分不是「user_id」碰巧所在的表的名稱，而是「user」是對象類術語，「id」該對象類的屬性之一。我正在使用對象,類和屬性不是OO編程意義上的，而是在ISO 11179元數據標準意義上。

您可以在線找到ISO 11179的草稿。我認爲這值得一讀。

如果您在單個查詢中使用多列（全部命名爲「id」），則無論如何您都必須至少使用其中一些列的別名。 40名不同程序員在10年或15年的工作期間每次都會使用相同的別名有什麼可能？在大型系統中，知道用戶的ID號在任何地方都會被命名爲「user_id」會有很大的價值。（除了可能在一個自我連接。）我已經在用戶的身份證號碼爲「user_id」，「usr_id」，「u_id」，「u_no」，「u_uno」，「u_n」，「u」，「uid」等。需要時間。時間可以更好地使用。

來源

2011-09-04 12:07:43

使用表名稱的前綴命名錶的列想法還是不好？

回答

相關問題