Составные первичные ключи в N-M отношении или нет? - PullRequest
Новая
       24

Составные первичные ключи в N-M отношении или нет?

2 голосов
/ 03 июня 2010

Допустим, у нас есть 3 таблицы (на самом деле у меня есть 2 на данный момент, но этот пример может лучше проиллюстрировать эту мысль):

[лицо]

  • ID: int, первичный ключ
  • Имя: nvarchar (xx)

[Группа]

  • ID: int, первичный ключ
  • Имя: nvarchar (xx)

[Роль]

  • ID: int, первичный ключ
  • Имя: nvarchar (xx)

[PersonGroupRole]

  • Person_ID: int, ПЕРВИЧНЫЙ КОМПОЗИТ ИЛИ НЕТ?
  • Group_ID: int, ПЕРВИЧНЫЙ КОМПОЗИТ ИЛИ НЕТ?
  • Role_ID: int, ПЕРВИЧНЫЙ СОСТАВ ИЛИ НЕТ?

Должен ли какой-либо из 3 идентификаторов в отношении PersonGroupRole быть помечен как ПЕРВИЧНЫЙ ключ или все они должны быть объединены в один составной файл? какая реальная выгода от этого или нет?

Я могу присоединиться в любом случае, насколько мне известно, поэтому Person JOIN PersonGroupRole JOIN Group сообщает мне, какие лица входят в какие группы и т. Д.

Я буду использовать LINQ / C # / .NET поверх SQL-экспресса и SQL-сервера, поэтому, если есть какие-либо причины в отношении языка / SQL, которые могут сделать выбор более ясным, об этой платформе я спрашиваю.

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

EDIT:

Хорошо, вопрос должен был быть неправильно понят, теперь я вижу.

Вопрос в том, имеет ли смысл помечать три идентификатора в PersonGroupRole как ПЕРВИЧНЫЕ КЛЮЧИ для целей индексации. Это добавит дополнительную скорость для объединения с каждой из трех таблиц, или они останутся без PRIMARY KEY в таблице PersonGroupRole и будут только первичными в отдельных таблицах.

Извините, по поводу путаницы. Постараюсь объяснить мои вопросы лучше.

Ответы [ 3 ]

6 голосов
/ 03 июня 2010

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

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

2 голосов
/ 03 июня 2010

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

2 голосов
/ 03 июня 2010

Это зависит от того, каковы отношения:

  • Может ли человек быть в более чем одной группе?
  • Есть несколько ролей?
  • Роль / группа 1: 1 с несколькими людьми в этой комбинации?
  • и т.д.

Скорее всего, вам нужно больше столов и 4NF или 5NF, чтобы захватить это

Пример здесь , но лучшая ссылка, которую я имел, теперь - какая-то дрянная страница ссылок. Другой, который описывает мои вопросы несколько

...