Question

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

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

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

这是一个关于数据库设计咆哮的邀请吗？嗯... OK。

数据库设计与OOP非常不同。数据库就是准确地表示世界的状态，而OOP的目标是完成任务。对象表示一个实体，而表中的一行表示一个（希望是真的）命题。

我对数据库设计的建议是逐字地为每个表构建一个命题，准确地说明该表中的行代表什么。然后设计系统，使这些命题始终为真（以及表represent false statements中任何缺失的行）。由于表格与对象根本不同，因此如果有助于准确表示所建模的事实，请不要害怕在多个表格中表示单个实体。

通常最好关注应该从数据生成哪种报告，而不是应用程序如何创建或使用数据。

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

Answer 4

ID是一个糟糕的名称，特别是在您进行报告并加入多个表时，您必须为所有这些ID字段设置别名，因为您在同一名称的报表中不能有多个字段。当您开始执行复杂查询时，ID会更加混乱。

Answer 5

我曾经普遍使用Id（选项3），虽然我认为我已经开始使用全名（EmployeeId），但明确的目的是让FK与PK名称相同。

工资肯定应该是选项2（EmployeeId）。 Salaries.Employee很糟糕，特别是如果你正在使用某种希望Employee成为引用实体的ORM。

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

5 个答案: