Должны ли быть названы столбцы в базе данных, имеющие отношение FK / PK? - PullRequest
0 голосов
/ 12 августа 2010

Как должны быть названы столбцы в таблице базы данных, имеющие отношение 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
)

У меня больше опыта в объектно-ориентированном программировании, чем в проектировании баз данных. С ООП при именовании свойств класса вы не захотите повторять имя класса, так как оно будет избыточным (Employee.ID, а не Employee.EmployeeID) Таким образом, я думаю, что лучше всего использовать вариант 3 сотрудника и вариант 1 зарплаты выше, так как я бы назвал свойства классов в ООП

.

Я прав? Есть ли что-то еще, что я должен рассмотреть, это относится к дизайну базы данных, который не относится к ООП?

Ответы [ 5 ]

3 голосов
/ 12 августа 2010

В ISO 11179 есть что сказать по поводу имен. Я рекомендую это.

Элементы данных всегда должны называться такими, какие они есть, а не по месту в структуре. Также они должны быть уникальными в пространстве имен, схеме или другом контексте, в котором они появляются. Имена должны содержать только общепринятые сокращения.

На этом основании EmployeeID - это разумное имя для идентификатора сотрудника. Идентификация - это плохое имя, потому что оно ничего вам не говорит.

Кроме того, очень широко распространено соглашение о том, что атрибуты внешнего ключа должны называться так же, как атрибуты ключа, на которые они ссылаются (потому что обычно они неявно являются одним и тем же элементом данных - только в разных таблицах). Единственный раз, когда я обычно нарушаю это правило, это если одна таблица содержит два внешних ключа, ссылающихся на один и тот же столбец в другой таблице. В этом случае имена, очевидно, должны отличаться, чтобы избежать конфликта имен.

1 голос
/ 14 августа 2010

ID - ужасное имя, особенно когда вы создаете отчеты и присоединяетесь к нескольким таблицам, вам все равно придется псевдоним всех этих полей идентификатора, поскольку в отчете не может быть нескольких полей с одинаковым именем. Идентификатор намного запутывает, когда вы начинаете делать сложные запросы.

1 голос
/ 13 августа 2010

@ 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,
)

Есть ли что-то еще, что я должен рассмотреть, чтоотносится к дизайну базы данных, который не относится к ООП?

Является ли это приглашение разглагольствовать о дизайне базы данных?Ну ... ОК.

Дизайн базы данных сильно отличается от ООП.БД - это точное представление о состоянии мира, в то время как цель ООП - это сделать что-то.Объект представляет собой сущность, в то время как строка в таблице содержит (надеюсь, истинное) предложение.

Мой совет для проектирования БД заключается в буквальном построении предложения для каждой таблицы, которое точно указывает, что представляет строка в этой таблице.,Затем спроектируйте систему так, чтобы эти предложения всегда были истинными (и любые пропущенные строки в таблице представляют ложные утверждения ).А поскольку таблицы принципиально отличаются от объектов, не бойтесь представлять одну сущность в нескольких таблицах, если это помогает точно представить моделируемые факты.

Часто лучше сосредоточиться на том, какие отчетыследует генерировать на основе данных, а не того, как приложение собирается создавать или использовать данные.

И в базовом отношении NULL означает «неизвестно».Это не значит «не применимо».Если есть место для неприменимых данных, значит что-то не так с дизайном.

1 голос
/ 12 августа 2010

Мне действительно больше нравится Option2, так как, если у меня есть несколько таблиц со столбцом ID (что я часто делаю), я могу записать его как E.EmployeeID, P.ProjectID, T.TaskID вместо E.ID, P.ID, T.ID, что является более читабельным IMO. Обычно столбцы отдельных таблиц отличаются настолько, что я делаю это только для столбца идентификатора.

0 голосов
/ 12 августа 2010

Раньше я использовал универсальный Id (вариант 3), хотя я думаю, что я пришел к использованию полного имени (EmployeeId) для явной цели того, чтобы FK были такими же именами, как и PK.обязательно должен быть вариант 2 (EmployeeId).Salaries.Employee отстой, особенно если вы используете какой-то ORM, который хочет, чтобы Employee был ссылочной сущностью.

...