Составные ключи дизайна базы данных

Question

Я собираюсь использовать надуманный пример: одна штаб-квартира имеет один или несколько контактов. Контакт может принадлежать только одной штаб-квартире.

---

TableName = Штаб-квартира

Столбец 0 = Id: Guid [PK]
Колонка 1 = Имя: nvarchar (100)
Столбец 2 = IsAnotherAttribute: bool

---

---

TableName = Контактная информация

Столбец 0 = Id: Guid [PK]
Столбец 1 = головной офис: Guid [FK]
Столбец 2 = AddressLine1
COlumn 3 = AddressLine2
Столбец 4 = AddressLine3

---

Мне нужна помощь в настройке первичных и внешних ключей таблицы?
Как выглядит выше?
Должен ли я использовать составной ключ для ContactInformation в [Столбец 0 и Столбец1]?
Можно ли использовать суррогатный ключ все время?

Answer 1

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

Лично я бы использовал Guids, только если бы мне действительно было нужно. В противном случае придерживайтесь брони. Я также склонен использовать суррогатные ключи почти везде.

Answer 2

Я бы держался подальше от составных ключей. Вопрос с суррогатным ключом обсуждается, но я всегда использую столбец INT Identity (в SQL Server), если мне это удается. Я использую GUIDS только в том случае, если база данных должна поддерживать репликацию или объединение распределенных данных.

Я думаю, что ваши столбцы выглядят нормально, кроме GUID.

Answer 3

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

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

Сказав это, мне не ясно, каковы вероятные ключи в вашем примере. Если Id является потенциальным ключом ContactInformation, то (HeadquarterId, Id) - нет, это суперключ, но он не является несводимым

Answer 4

Наряду с суррогатным ключом (идентификатором GUID) часто рекомендуется идентифицировать бизнес-ключ (естественный ключ / ключ домена) на основе бизнес-атрибутов, определяющих сущность.

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

Я согласен, что ПК должен быть простым, а не составным. С составными ПК работать очень сложно, а запросы становятся все более сложными.

Answer 5

Я бы сказал, что ваш первичный ключ должен быть Id. Составной ключ на ContactInformation из Id и HeadquarterID может иметь смысл, если вы будете часто использовать эти две части информации вместе, но я бы предпочел использовать просто Id в качестве ключа, а затем вы можете создать индекс на Id и HeadquarterID, если вам действительно нужно.