是否应该命名数据库中具有FK / PK关系的列？

Question

如何命名数据库表中具有PK / FK关系的列？ 它们的名称是否应该包含对其所在表的引用？ 请考虑以下示例。 每个员工在工资表中都有一个FK的ID。

/* 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）。 因此，我认为上面的Employee Option 3和Salary Option 1最好，因为这就是我在OOP中命名类的属性的方式。

我对吗？ 我还应该考虑其他不适用于OOP的数据库设计吗？

Answer 1

ISO 11179对于命名有一些不错的建议。 我推荐它。

数据元素应始终按其名称命名，而不应按其在结构中的位置命名。 同样，它们在它们出现的名称空间，架构或其他上下文中应该是唯一的。 名称应仅包含通常理解的缩写。

在此基础上，EmployeeID是员工标识符的合理名称。 ID是一个坏名字，因为它告诉您没有什么用。

同样，一个广泛观察到的约定是，外键属性应与它们引用的键属性命名相同（因为通常它们隐式地是相同的数据元素-只是在不同的表中）。 我通常会打破该规则的唯一时间是，如果一个表包含两个引用另一个表中同一列的外键。 在那种情况下，名称显然需要不同，以避免命名冲突。

Answer 2

我实际上最喜欢Option2，因为如果我有几个带有列ID表（我经常这样做），我可以将其写为E.EmployeeID, P.ProjectID, T.TaskID而不是E.ID, P.ID, T.ID ，这是更易读的IMO。 通常，单独表的列之间的差异足以使我仅对ID列执行此操作。

Answer 3

@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的数据库设计吗？

这是关于数据库设计的邀请吗？ 好吧...好

数据库设计与OOP有很大不同。 DB就是要准确地表示世界状况，而OOP的目标是完成工作。 一个对象代表一个实体，而表中的一行则表示一个（希望是正确的）命题。

我对数据库设计的建议是为每个表按字面意义构造一个命题，以准确说明该表中的行表示什么。 然后设计系统，使这些命题始终为真（并且表中所有遗漏的行均代表假语句 ）。 并且由于表与对象在本质上是不同的，因此如果可以帮助准确地表示要建模的事实，请不要害怕在多个表中表示单个实体。

通常最好将重点放在应该从数据生成什么样的报告上，而不是应用程序将如何创建或使用数据。

在基本关系中，NULL表示“未知”。 这并不意味着“不适用”。 如果存在用于不适用数据的空间，则设计有问题。

Answer 4

ID是一个很糟糕的名称，尤其是当您在执行报告并连接到多个表时，由于您在同一个名称的报告中不能有多个字段，因此无论如何都必须为所有这些ID字段加上别名。 当您开始进行复杂的查询时，ID会更加令人困惑。

Answer 5

我曾经普遍使用Id（选项3），尽管我认为使用全名（EmployeeId）是为了使FK与PK具有相同的名称。

工资绝对应该是选项2（EmployeeId）。 Salaries.Employee很烂，尤其是在您使用某种ORM希望Employee作为引用实体的情况下。