Что бы это значило, если бы я изменил идентификационные отношения с этой части структуры базы данных на неидентифицирующие отношения? - PullRequest
Новая
       1

Что бы это значило, если бы я изменил идентификационные отношения с этой части структуры базы данных на неидентифицирующие отношения?

1 голос
/ 06 сентября 2010

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

У меня есть такой дизайн базы данных: (что-то вроде магазинов проката фильмов. "Друг" - это те, кто одалживает фильм. "Студия" - продакшн-студия, которая сотрудничала в создании фильма.)

Sample.png

Я немного понимаю, как это работает. Однако мне было интересно, что если я создам loan_id в таблице ссуд и использую movie_id и friend_id в качестве обычных внешних ключей?

Вот некоторые из моих вопросов: Каковы преимущества или недостатки более позднего подхода? Ситуация, когда начальная или более поздняя модель лучше? Позволяет ли первоначальная модель другу одолжить фильм более одного раза?

Любое подробное объяснение будет высоко ценится.

Ответы [ 2 ]

2 голосов
/ 06 сентября 2010

То, как у вас есть все ваши таблицы «многие ко многим» (совместная работа с таблицами, заем, роль), называется составным первичным ключом: где два (или более) столбца образуют уникальное значение.

Когда у вас есть составной pk, многие разработчики БД предпочитают создавать суррогатный первичный ключ (например, предложенный loan_id).Я один из них.Этот пост хорошо объясняет, почему или почему нет: Составные первичные ключи в сравнении с уникальным полем идентификатора объекта .

Моя относительно простая причина для этого заключается в том, что составные ключи имеют тенденцию к росту.: На примере ссуды, что произойдет, если эти фильмы ссудятся несколько раз?Используя составной подход, вам нужно будет добавить loan_date в составной ключ.

Что, если вы хотите отслеживать какие-либо повторные займы?Затем вам потребуется вторая таблица, содержащая все составные поля pk из таблицы ссуд (original_loan_movie_id, original_loan_friend_id, original_loan_date), просто чтобы сослаться на исходный заем ...

0 голосов
/ 06 сентября 2010

В таблице LOAN вы должны гарантировать уникальность следующих столбцов:

  • movie_id (замените на copy_id при условии, что имеется несколько копий фильма)
  • friend_id
  • loan_date

... потому что я или кто-либо другой должен иметь возможность снимать один и тот же фильм более одного раза. Это также столбцы, которые чаще всего нужно искать ...

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

Но это делает запросы проще ...

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

Но составные ключи сложны ...

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

Подход одиночного первичного ключа означает, что loan_id индексируется с наилучшим индексом для таблицы (SQL Server и MySQL называют их кластерными индексами, для Oracle они все являются просто индексами) и требуют дополнительного составного уникального ограничения / индекс. Для некоторых баз данных может потребоваться дополнительная индексация, выходящая за пределы уникального ограничения ... Таким образом, это делает модель данных более сложной / сложной и бесполезной:

  • Некоторые базы данных, такие как MySQL, ограничивают объем пространства, которое вы можете использовать для индексов.
  • первичный ключ получает самый идеальный индекс, но значение не имеет отношения к данным в таблице, поэтому использование индекса, связанного с первичным ключом, будет редко, если вообще когда-либо.

Заключение

Мне еще предстоит увидеть законное обоснование для первичного ключа из одного столбца над составным первичным ключом.

...