Композитные первичные ключи в отношении N-M или нет?

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

[Person]

ID: INT, первичный ключ
Имя: NVARCHAR (хх)

[Группа]

ID: INT, первичный ключ
Имя: NVARCHAR (хх)

[Роль]

ID: INT, первичный ключ
Имя: NVARCHAR (хх)

[PersonGroupRole]

person_id: INT, ОСНОВНОЙ КОМПОЗИТНО или нет?
Group_ID: int, ПЕРВИЧНЫЙ КОМПОЗИТ ИЛИ НЕТ?
Роль_ID: int, ПЕРВИЧНЫЙ КОМПОЗИТ ИЛИ НЕТ?

Если какой-либо из 3-х идентификаторов в отношении PersonGroupRole быть помечен как первичный ключ или все должны 3 они будут объединены в один композит ?? Какая реальная польза от этого или нет?

я могу присоединиться в любом случае, насколько я знаю, так Person РЕГИСТРИРУЙТЕСЬ PersonGroupRole РЕГИСТРИРУЙТЕСЬ Группу дает мне, которые лицо, в которых группа и т.д.

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

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

EDIT:

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

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

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

источник

2010-06-03 BerggreenDK

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

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

источник

2010-06-03 18:08:41

Я бы сказал, что это сложнее, чем избежать аномалий I/U/D. Что дает вам суррогат? – gbn

Суррогатный ключ упростил бы объединение * ЕСЛИ * появились дополнительные таблицы, в которых PersonGroupRole был бы как родительская таблица. Без суррогатного ключа вам нужно будет включить все три столбца в эту (новую) дочернюю таблицу и сделать их частью своего первичного ключа в сочетании с тем, какие новые данные идентифицируют/требуют, чтобы дочерняя таблица (например, DateCreated) , Есть аргументы для и против обоих, и мир «зависит» от ваших конкретных обстоятельств, чтобы рассмотреть, прежде чем принимать окончательное решение. –

Хорошо, очистка: эта проблема, вероятно, намного проще, чем я написал вопрос. Извините за все пух. Каждая таблица объединяется с помощью «N-M», поэтому одно Лицо находится в нескольких группах и имеет несколько ролей. Но давайте удалим роли для простоты. Я спрашиваю, должна ли таблица отношений «N-M» иметь внешние идентификаторы, помеченные как PRIMARY KEYS (index), или нет. Это хорошо для SQL-сервера или плохого, так как они также являются PRIMARY Keys в их «домашней таблице» (например, Person) - может быть вопросом новичков, но я не могу вспомнить или найти лучший ответ. – BerggreenDK

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

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

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

Example here, но лучшая ссылкой я имел теперь некоторые дерьмовая ссылку на этой странице извините. Another that describes my questions somewhat

источник

2010-06-03 18:06:50 gbn

Aahh, я вижу возможное замешательство. Извините, для простоты просто удалите 3-й столбец. Просто [Person] [in] [Group]. Каждый человек может находиться в каждой группе, и каждая группа может содержать каждую группу. Это не «данные», а больше идея маркировки двух иностранных идентификаторов как первичных ключей или нет в отношении N-M. Кажется, я забыл свои основы SQL на этом. Меня беспокоит слишком много или слишком мало индексирования, связанное с «средним отношением». – BerggreenDK

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

источник

2010-06-03 18:49:48 sqlvogel

Композитные первичные ключи в отношении N-M или нет?

ответ

Смежные вопросы