Нужно ли определять новое поле первичного ключа для каждой таблицы?

Question

У меня есть несколько таблиц базы данных, которые действительно требуют только уникальный идентификатор, который ссылается на другую таблицу, например,

Customer      Holiday
********      *******
ID (PK)  ---> CustomerID (PK)
Forename      From
Surname       To
....

Эти таблицы, такие как Holiday, существуют только для хранения информации о Клиенте. Поэтому нужно ли указывать отдельное поле для хранения идентификатора праздника? т.е.

Holiday
*******
ID (PK)
CustomerID (FK)
...

Или я мог бы в этом случае просто установить CustomerID в качестве первичного ключа в таблице?

С уважением, Джеймс.

Answer 1

Это действительно зависит от того, что вы делаете.

если у каждого клиента может быть только 1 выходной, то да, вы можете сделать кастомерид первичным ключом.

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

Кроме того, если у каждого клиента может быть только 1 выходной, я бы просто добавил информацию о выходных днях в таблицу, поскольку отношения один к одному обычно не нужны.

Answer 2

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

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

Кроме того, это дает вам больше возможностей для расширения вашего решения в будущем. У вас может быть только один выходной день для каждого клиента, но изменить его гораздо сложнее, если вы сделаете ID клиента первичным ключом.

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

Answer 3

Предыдущий ответ правильный, но также помните, что в каждой таблице может быть 2 отдельных первичных ключа, а в таблице "holiday" будет внешний ключ для CustomerId.

Тогда вы можете управлять назначением выходных для клиентов в своем коде, чтобы убедиться, что клиенту может быть назначен только один выходной, но это приводит к проблеме параллелизма, так как 2 человека добавляют выходной для клиента в то же самое время, скорее всего, приведет к тому, что у клиента будет 2 отпуска.

Вы можете даже поместить поля праздников в таблицу клиентов, если клиент может быть создан только с праздником, но этот дизайн не очень удобен и не рекомендуется

Итак, еще раз, вариант в вашем вопросе 2 по-прежнему лучший путь, просто давая вам ваши варианты.

Answer 4

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

Ваш второй проект гарантирует, что каждый экземпляр Holiday может быть уникально идентифицирован и обработан приложением OO, используя простое объектно-реляционное отображение.

Как правило, лучше всего убедиться, что у каждого объекта в базе данных есть уникальный, неизменный, назначаемый системой («суррогатный») ключ. Другие «естественные» ключи могут иметь уникальные индексы, ограничения и т. Д., Чтобы соответствовать бизнес-логике.

Answer 5

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