Должен ли я использовать первичный ключ здесь?

Question

Как пример, У меня есть 3 таблицы:

School: ID int, Name varchar

Student: ID int, Name varchar

StudentInSchool: StudentID int, SchoolID int

Теперь возникает вопрос стоит ли мне ставить столбец ID int с первичным ключом в таблице StudentInSchool ? Если да, то почему?

Будет ли это полезно при индексации?

Любая помощь приветствуется.

Answer 1

Лично я создаю составные PK (StudentID и SchoolID) для таких соединительных таблиц . Это также гарантирует уникальность.

Если, однако, уникальность не требуется, вам придется добавить столбец ID, чтобы однозначно идентифицировать каждую строку.

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

Answer 2

Создайте первичный ключ на StudentID, SchoolID и вторичный индекс на SchoolID или наоборот, в зависимости от того, какое условие поиска используется чаще.

Если ваша таблица организована по индексу (ORGANIZATION INDEX в Oracle, CLUSTERED в SQL Server, InnoDB в MySQL), то вторичный индекс будет иметь PRIMARY KEY в качестве крайней левой части и, следовательно, вся информация может быть получена из индекса.

Answer 3

Хорошо, я думаю, что в задании чего-то не хватает, поэтому я попытаюсь с моим плохим знанием реального мира: о)

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

Достаточно ли соединительной таблицы как есть (с PK над обоими идентификаторами), чтобы смоделировать эти отношения?

короткий ответ: нет

длинный ответ: все еще нет, но для подмножества простых случаев этого достаточно (у вас один из них?).

Если вы хотите расширить db позже для всех этих случаев, потребуется суррогатное PK (ваш ID). Я бы поставил ID там, если у меня есть только сомнения, что это может потребоваться (так как не так много, чтобы потерять).

Как указано в первом предложении, правильный ответ: «Мы не знаем», поскольку отсутствуют требования и контекст применения.

Answer 4

Вы можете объединить StudentID и SchoolID в один первичный ключ.

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

Источник: Индексы SQL

Answer 5

С точки зрения чистой целостности данных: нет. Вполне достаточно определить первичный ключ как (StudentID, SchoolID).

Однако вы не говорите, какую СУБД вы используете. Возможно, для некоторых из них один столбец идентификаторов приведет к более эффективным планам запросов.

В случае SQL Server составной первичный ключ из двух целых чисел очень эффективен, и никаких дополнительных индексов для двух столбцов не требуется.

Answer 6

Ответ, это зависит. В большинстве случаев ответ «Нет»: достаточно составного первичного ключа (StudentID, SchoolID).

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

Answer 7

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

Но если это дизайн, то да, вы не потеряете ничего, поместив первичный ключ в таблицу StudentInSchool.