爲什麼在列名中指定主鍵/外鍵屬性

一些最近的問題討論了命名列的策略，我很驚訝地發現在列名中嵌入外鍵和主鍵的概念。也就是說爲什麼在列名中指定主鍵/外鍵屬性

select t1.col_a, t1.col_b, t2.col_z 
from t1 inner join t2 on t1.id_foo_pk = t2.id_foo_fk

我不得不承認我從來沒有使用這種方案的任何數據庫系統的工作，我想知道的好處是什麼。我看到它的方式，一旦你瞭解了系統的N個主要表格，你就會用這些表格寫出幾個數量級的請求。

爲了提高開發效率，您需要了解哪些表格是重要的表格，哪些是簡單的支流。你會想要提交大量的列名到內存中。其中一項基本任務是將兩張桌子連在一起。爲了降低學習努力，以最簡單的事就是確保列名是相同的兩個表中：

select t1.col_a, t1.col_b, t2.col_z 
from t1 inner join t2 on t1.id_foo = t2.id_foo

我斷定，作爲一個開發者，你並不需要提醒的是，很多關於哪些列是主鍵，哪些是外鍵，什麼都不是。如果你很好奇，看看這個模式是很容易的。當看隨機

tx inner join ty on tx.id_bar = ty.id_bar

......知道哪一個是外鍵是重要的嗎？外鍵僅對數據庫引擎本身很重要，以確保參照完整性並在更新和刪除過程中做正確的事情。

這裏解決了什麼問題？（我知道這是一個討論的邀請，並且可以隨意這樣做，但同時我也在尋找答案，因爲我可能真的錯過了一些東西）。

來源

2008-10-17 dland

我同意你的子表中的外鍵列應該與父表中的主鍵列具有相同的名稱。請注意，這允許類似下面的語法：

SELECT * FROM foo JOIN bar USING (foo_id);

using關鍵字假設一列由同一名稱存在兩個表中，並且要等值連接。很高興有這個可作爲簡寫更詳細：

SELECT * FROM foo JOIN bar ON (foo.foo_id = bar.foo_id);

不過要注意，有些時候你不能命名外鍵一樣，它引用主鍵的情況。例如，在具有自引用的表中：

CREATE TABLE Employees (
    emp_id INT PRIMARY KEY, 
    manager_id INT REFERENCES Employees(emp_id) 
);

另外一個表可能有多個外鍵到同一個父表。這是非常有用使用的列的名稱來形容這種關係的性質：

CREATE TABLE Bugs (
    ... 
    reported_by INT REFERENCES Accounts(account_id), 
    assigned_to INT REFERENCES Accounts(account_id), 
    ... 
);

我不喜歡以包括列名的表的名稱。我也避開了強制性的「id」作爲每個表中主鍵列的名稱。

來源

2008-10-17 23:17:20

我同意你的意見。將這些信息放在欄目名稱中，以表示早期Windows時代的糟糕的匈牙利符號白癡。

來源

2008-10-17 22:31:28

-1

我同意你的看法 - 我拿，我已經看到了許多企業環境推薦了不同的方法：在格式

名稱列TableNameFieldName，所以如果我有一個客戶表和用戶名是一個我的字段，該字段將被稱爲CustomerUserName。這意味着如果我有另一個名爲Invoice的表，並且客戶的用戶名是外鍵，我將其稱爲InvoiceCustomerUserName，當我引用它時，我將其稱爲Invoice.CustomerUserName，它立即告訴我它在哪個表中。

另外，這個命名可以幫助你跟蹤你的列在來自你的時候的表格。

我只在DBMS中的外鍵和主鍵的ACTUAL名稱中使用FK_和PK_。

來源

2008-10-17 22:32:57

豈不它是Invoice.InvoiceCustomerUserName？這有可能比類型標籤更糟...... Invoice.UserName = Customer.UserName對我來說似乎已經足夠清晰了。 – 2008-10-17 22:55:46

對不起，這太可怕了。簡直可怕。它看起來像是一種「巧妙」，可以避免使用表別名。幾乎和我工作的地方一樣糟糕，其中表名前綴爲T_和列C_（視圖和索引也有前綴...） – 2008-10-18 00:07:51

我在表的任何外鍵的前端使用「fk_」主要是因爲它幫助我在開發商店項目的數據庫時保持直線。過去沒有做過任何數據庫工作，這對我有幫助。事後看來，也許我不需要那麼做，但是在某些專欄名稱上加了三個字符，所以我沒有出汗。作爲編寫數據庫應用程序的新手，我可能做出了一些決定，這將使經驗豐富的數據庫開發人員感到不寒而慄，但我不確定外部關鍵事情真的是什麼大不了的事情。再次，我想這是一個關於這個問題的觀點上的差異，我一定會拿你寫的和認真的。

有一個好的！

來源

2008-10-17 22:45:17 itsmatt

我只使用具有主鍵的Id後綴的表名，例如， CustomerId和引用其他表的外鍵也將被稱爲CustomerId。當你在應用程序中引用時，它很容易從對象屬性中得到表格，例如Customer.TelephoneNumber，Customer.CustomerId等

來源

2008-10-17 22:48:01 Turnkey

在我用SQL數據庫開發的20多年的時間裏，我一直贊同這裏提出的大多數想法，我很尷尬地說。他們中的大多數人提供了很少或沒有預期的好處，並且事後看來是痛苦的脖子。

任何時候我花了超過幾個小時的模式，我已經很快熟悉了最重要的表格和它們的列。一旦到了幾個月，我就會把所有的東西都放在我的腦海裏。

這是誰的全部解釋？無論如何，只花費幾分鐘時間完成設計的人不會做任何事情。如果你用梵文命名你的專欄，那麼計劃長期使用它的人會學習它。

忽略複合主鍵，我不明白爲什麼像「id」這樣簡單的東西不足以用於主鍵，而「_id」用於外鍵。

所以一個典型的連接條件變成customer.id = order.customer_id。

如果存在兩個表之間的多個協會，我會傾向於使用關聯，而不是表名，所以也許「PARENT_ID」和「child_id」，而不是「parent_person_id」等

來源

2008-10-18 00:19:56

爲什麼在列名中指定主鍵/外鍵屬性

回答

相關問題