應該命名數據庫中具有FK/PK關係的列嗎？

數據庫表中具有PK/FK關係的列應該如何命名？他們的名字是否應該包含對他們所在表格的引用？考慮下面的例子。每位員工在薪資表中都有一個FK。應該命名數據庫中具有FK/PK關係的列嗎？

/* Employees Option 1*/ 
CREATE TABLE dbo.Employees 
( 
    EmployeeID INT PRIMARY KEY, 
    EmployeeFirstName VARCHAR(32), 
    EmployeeLastName VARCHAR(32), 
    EmployeeEmail VARCHAR(255) -- , ... 
) 


/* Employees Option 2*/ 
CREATE TABLE dbo.Employees 
( 
    EmployeeID INT PRIMARY KEY, 
    FirstName VARCHAR(32), 
    LastName VARCHAR(32), 
    Email VARCHAR(255) -- , ... 
) 

/* Employees Option 3*/ 
CREATE TABLE dbo.Employees 
( 
    ID INT PRIMARY KEY, 
    FirstName VARCHAR(32), 
    LastName VARCHAR(32), 
    Email VARCHAR(255) -- , ... 
) 

/* Salaries Option 1*/ 
CREATE TABLE dbo.Salaries 
( 
    EmployeeID INT, 
    Salary INT 
) 

/* Salaries Option 2*/ 
CREATE TABLE dbo.Salaries 
( 
    Employee INT, 
    Salary INT 
)

我對面向對象編程和數據庫設計有更多的經驗。使用OOP命名類的屬性時，您不希望重複該類的名稱，因爲它是多餘的（Employee.ID不是Employee.EmployeeID）。因此，我認爲以上員工選項3和薪金選項1是最好的，因爲我如何命名OOP中的類屬性

對嗎？有什麼我應該考慮適用於不適用於OOP的數據庫設計？

來源

2010-08-12 Eric Anastas

對於命名，ISO 11179有一些很好的說法。我推薦它。

數據元素應該始終按照它們的名稱命名，而不是按照它們在結構中的位置命名。它們也應該在名稱空間，模式或它們出現的其他上下文中是唯一的。名稱應該只包含通常理解的縮寫。

在此基礎上，EmployeeID是員工標識符的合理名稱。 ID是一個糟糕的名字，因爲它告訴你什麼都沒有用。

而且，這是一個非常普遍觀察約定外鍵的屬性應該被命名一樣，他們引用（因爲通常它們是隱含相同的數據元素 - 只是在不同的表）的關鍵屬性。我通常會違反該規則的唯一時間是如果一個表包含引用另一個表中同一列的兩個外鍵。在這種情況下，名稱顯然需要不同以避免命名衝突。

來源

2010-08-12 19:40:42 sqlvogel

我其實很喜歡Option2，因爲如果我有幾列表ID（我經常這樣做），我可以將它寫爲E.EmployeeID, P.ProjectID, T.TaskID而不是E.ID, P.ID, T.ID，這是更易讀的IMO。通常，單獨表的列是不同的，我只對ID列做這些。

來源

2010-08-12 18:34:40

請參閱我在想我希望表的主鍵列始終爲ID，然後是另一個表中的任何列，該列是該名爲EmployeeID的表的foriegn鍵。這樣，如果我看到名爲ID的列，我知道它是該表的ID，並且如果我看到名爲EmployeeID的列，那麼我知道它是指Employee表的ID列。否則，您最終可能會得到一個名稱，例如Employee.EmployeeID和Salaries.EmployeeID，其中關係的方向並不明顯。 – 2010-08-12 18:41:24

@Eric，對我來說'Employees.EmployeeID'作爲主鍵很明顯。你只需要小心你的表格命名。 – 2010-08-12 18:43:07

對我來說，這看起來多餘。這也似乎是我一直在關注的大多數例子都遵循這種命名方式，而且我更願意遵循人們最經驗的做法。雖然我認爲有兩種方法可以很好地工作。 Employee.EmployeeID和Salaries.Employee或Empoyee.ID和Salaries.EmployeeID。第一種更常見的是？ – 2010-08-12 19:01:00

我以前普遍使用的ID（選項3），但我想我已經圍過來使用全名（僱員），對於具有FKS是相同名稱的PK的明確目的。

薪金一定是選項2（EmployeeId）。薪酬。員工太多了，特別是如果您使用某種希望員工成爲引用實體的ORM。

來源

2010-08-12 19:42:52 Shlomo

@dportas覆蓋了很好的主要觀點。

下面是如何定義這些表的示例。

create table dbo.Employee 
(
    EmployeeId int not null primary key, 
    FirstName nvarchar(100) not null, 
    LastName nvarchar(100) not null, 
    Email nvarchar(255) not null, 
) 

create table dbo.Salary 
(
    EmployeeId int not null 
     foreign key references dbo.Employee (EmployeeId), 
    BeginDate datetime not null, 
     primary key (EmployeeId, BeginDate), 
    EmploymentClassificationId int not null 
     foreign key references dbo.EmploymentClassification (EmploymentClassificationId), 
    PerWeekAmount money not null, 
)

有沒有別的東西，我應該考慮適用於數據庫的設計，並不適用於OOP？

這是一個邀請咆哮有關數據庫設計的？嗯... OK。

數據庫設計與OOP非常不同。數據庫是關於準確表示世界的狀態，而OOP的目標是完成任務。一個對象表示一個實體，而表中的一行表示一個（希望是正確的）命題。

我對數據庫設計的建議是從字面上爲每個表格建立一個命題，確切說明該表格中的一行。然後設計系統，使這些命題永遠是真實的（並從表represent false statements表中任何缺失的行）。而且，由於表格與對象有根本的不同，如果能夠準確地表示正在建模的事實，就不要害怕在多個表格中表示單個實體。

通常最好關注應該從數據生成哪種報告，而不是應用程序將如何創建或使用數據。

而在基礎關係中，NULL表示「未知」。這並不意味着「不適用」。如果存在不適用數據的空間，那麼設計有些問題。

來源

2010-08-12 20:12:56

當然，使用面向對象原則設計關係型數據庫會適得其反，而且一般來說是一個壞主意。數據庫是一個不同的動物，瞭解什麼對他們更好。在設計數據庫和規範化時學習集合論。 – HLGEM 2010-08-13 21:28:34

ID是一個可怕的名字，尤其是當您要進行報告並連接到多個表時，由於無法在報表中使用相同名稱的多個字段，因此您必須爲所有這些ID字段設置別名。當你開始進行復雜的查詢時，ID更加令人困惑。

來源

2010-08-13 21:26:25 HLGEM

應該命名數據庫中具有FK/PK關係的列嗎？

回答

相關問題