В качестве примера, У меня есть 3 таблицы:Должен ли я использовать Первичный ключ здесь?
School: ID int, Name varchar
Student: ID int, Name varchar
StudentInSchool: StudentID int, SchoolID int
Теперь вопрос должен ли я поставить колонку ID int с первичным ключом на нем в StudentInSchool таблице? Если да, то почему?
Будет ли полезно индексировать?
Любая помощь приветствуется.
Лично я создаю композитные ПК (StudentID и SchoolID) на таких junction tables. Это также гарантирует уникальность.
Если, однако, уникальность не требуется, вам нужно будет добавить столбец ID, чтобы однозначно идентифицировать каждую строку.
Вообще говоря, добавление отдельного столбца ID не поможет: очень мало запросов (если они есть) фактически будут использовать этот столбец. Что касается производительности, вы можете создать отдельный индекс для каждого столбца, и вы будете в порядке.
Создайте первичный ключ на StudentID, SchoolID и вторичный индекс на SchoolID, или наоборот, в зависимости от того, какое условие поиска используется чаще.
Если таблица индекс организована (ORGANIZATION INDEX в Oracle, CLUSTERED в SQL Server, InnoDB в MySQL), то вторичный индекс будет иметь PRIMARY KEY как крайнюю левую часть и, следовательно, вся информация может быть извлечена из индекса.
Ответ, это зависит. В большинстве случаев ответ «Нет»: достаточно основного первичного ключа (StudentID, SchoolID).
Но если эта таблица пересечений начинает приобретать другие связанные данные (например, дату присоединения, дату окончания) и/или становится родителем связанных таблиц (например, запись посещаемости), тогда вы можете захотеть или ее рассматривать как правильный таблица. В этом случае (StudentID, SchoolID) становится бизнес-ключом (то есть все еще уникальным), и вы добавляете синтетический (или суррогатный) первичный ключ Id или что-то еще.
С точки зрения чистой целостности данных: нет. Достаточно определить первичный ключ как (StudentID, SchoolID).
Однако вы не говорите, какую СУБД вы используете. Возможно, для некоторых из них один столбец идентификатора приведет к созданию более эффективных планов запросов.
В случае SQL Server составной первичный ключ из двух целых чисел является очень эффективным, и в двух столбцах не требуются дополнительные индексы.
В этом примере, если таблица StudentInSchool не будет иметь других атрибутов, например. временные метки, когда студент находился в этой школе, чтобы справиться с ходами, я бы не использовал его, и я бы поместил поле schoolID в таблицу Student и определил его как внешний ключ.
Но если это дизайн, то да, вы ничего не потеряете, поместив первичный ключ в таблицу StudentInSchool.
Вы можете комбинировать StudentID и SchoolID с одним первичным ключом.
Есть некоторые общие правила, которые описывают, когда следует использовать индексы. Когда , касающийся относительно небольших таблиц, индексы не улучшают производительность. В общие индексы повышают производительность , когда они создаются в используемых полях в таблицах. Используйте индексы, когда большинство ваших запросов к базе данных извлекают относительно небольшие наборы данных, потому что если ваши запросы извлекают большую часть данных , то в большинстве случаев индексы будут фактически замедляют извлечение данных. Используйте индексы для столбцов, которые имеют множество значений (в столбце не так много ). Хотя индексы улучшают поиск производительность, они замедляют обновления, , и это может быть что-то стоящее рассмотрение.
Источник: SQL Indexes
Хорошо, я думаю, что есть что-то отсутствует в задании, так что я постараюсь с моим плохим знанием реального мира: о)
Что студенты? Они ходят в школу (-ы), могут учиться в более чем одной школе (особенно в университетах), они могут даже повторить одну и ту же школу позже и т. Д.
Является ли таблица соединений как есть (с PK по обеим идентификаторам) достаточно моделировать эти отношения?
короткий ответ: нет
длинного ответа: до сих пор нет, но для подмножества простых случаев достаточно (за вами один из них?).
Если вы хотите продлить db позже для всех этих случаев, потребуется суррогатная PK (ваш идентификатор). Я бы поставил там ID, если у меня есть сомнения, что это может потребоваться (так как нечего терять).
Как указано в первом предложении - правильный ответ: «Мы не знаем», поскольку отсутствуют требования и контекст приложения.
+1. Я принимаю тот же подход – Alex
Зависит от мощности отношения, которое мы хотим описать, используя таблицу переходов. Принудительная взаимная корреляция может иметь неприятные последствия, когда мы пытаемся моделировать реальный мир. –