Должен ли я иметь первичный ключ для ассоциативной таблицы, если на него нужно ссылаться из другой таблицы - PullRequest
Новая
       11

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

0 голосов
/ 10 декабря 2018

Я создаю базу данных для базы данных о недвижимости и жилой недвижимости.

Вот требования.

  1. Владелец может владеть многими свойствами.

  2. У собственности может быть много владельцев (совместная собственность с супругом, родственниками и т. Д.)

Итак, у меня есть ассоциативная таблица, так как Owner-Property является многозначныммногие отношения.

Owner_Property

  • 1-й атрибут: идентификатор владельца (FK для таблицы Owner)

  • 2-й атрибут: лот свойстваid (FK к таблице свойств)

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

Поэтому я подумалсоздания другой ассоциативной сущности, Duration_of_stay_at_Property, где первый атрибут - month_id, а другой атрибут свяжется с таблицей Owner_property, либо через Fk для составных ключей, либо первичный ключ, который необходимо будет создать в Owner_propertyТаблица.

Что вы предлагаете о тон ПК / составное решение?Есть ли какие-либо улучшения, вы хотите предложить дизайн?

Ответы [ 4 ]

0 голосов
/ 10 декабря 2018

Я полагаю, что Владение (многие: много сопоставлений между владельцами и свойствами) не зависит от того, кто там находится, когда.Сделайте две таблицы.

Таблица owner_property должна иметь два столбца (без auto_increment);PK должен иметь оба столбца, и вам, вероятно, нужен индекс со столбцами в обратном порядке. Дополнительные обсуждения и советы

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

(ОК, я в значительной степени говорю то, что говорили другие Ответы.)

0 голосов
/ 10 декабря 2018

Я бы выбрал следующее решение:

  • добавить первичный ключ в таблицу Owner_Property

  • ссылка Duration_of_stay_at_Property напервичный ключ Owner_Property (наряду с другой информацией, такой как месяц пребывания)

Обоснование этого:

  • обычноХорошей практикой является использование первичного ключа в большинстве таблиц

  • . Первичный ключ устраняет необходимость в составном ключе foregin для Duration_of_stay_at_Property (без первичного ключа вам нужно два столбца дляотносятся к строке в Owner_Property)

0 голосов
/ 10 декабря 2018

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

Таким образом, это предполагает таблицу типа staying с атрибутами для:

  • владельца / свойствапервичный ключ
  • дата начала
  • дата окончания
  • любая другая соответствующая информация

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

0 голосов
/ 10 декабря 2018

... необходимо хранить информацию, о которой месяцы конкретный владелец остается в соответствующем свойстве ...

В этом предложении открыто говорится о том, что вам нужен новый объект с составным ключом из трех столбцов.Примерно так: 

dwelling (month, owner_id (FK), property_id (FK))

Иногда, когда у вас есть дополнительные сущности, связанные с dwelling, вы можете добавить дополнительный PK с одним столбцом, помня о том, что вам также нужно сохранить основной уникальныйограничение.Что-то вроде: 

dwelling (dwelling_id, month, owner_id (FK), property_id (FK))
  + constraint unique (month, owner_id, property_id)
...