Проектирование базы данных SQL

Question

Я создаю базу данных для программы, в которой мне предстоит моделировать некоторые отношения в семье.бывший:X — отец Y, Y — сын X

Итак, у меня есть Члены таблица со всей информацией о каждом члене, поэтому я подумал о том, чтобы создать связь многие-ко-многим между Члены таблицу и себя так, чтобы Member_Member таблица моста будет иметь столбцы "FK_FromID, FK_ToID" как составной ключ (это правильно?) и "FK_RelationType" как внешний ключ к Типы отношений таблица, которая будет иметь тип отношения «Отец, мать, сын, дочь» и два отношения, идущие как одно ко многим из таблицы Members к этим двум внешним ключам

Моя проблема в том, :при удалении, если я выберу каскадирование, я буду делать циклы, потому что если я удалю член, то будет два прохода удаления для связанных записей в Member_Member Bridge, зная, что в программе всякий раз, когда я вставляю отношение отца, я также вставляю отношение сына в таблицу Member_Member, есть ли способ или обходной путь, чтобы включить каскадирование, чтобы всякий раз, когда я удаляю член, я удалял связанные записи в Member_member независимо от того, записано ли оно в столбце внешнего ключа to или from

Итак, я не знаю, что делать, это вообще правильный дизайн или что?, что мне делать с ездой на велосипеде, и что, по вашему мнению, лучший дизайн для той же проблемы должен знать, что мне нужно указать, какие отношения между двумя сторонами

Большое спасибо за любую помощь, и извините за плохой английский, Бишой

Answer 1

SQL не очень хорошо справляется с подобными «сетевыми» проблемами.

Таблица мостов членов-членов — ужасное имя.Это мост «член-родитель» (или «родитель-ребенок»).Таблицы моста не должны иметь «составного ключа».Таблицы моста имеют суррогатный ключ (просто порядковый номер) и пару ссылок FK на другие таблицы.Два FK должны иметь такие имена, как «член» и «родитель», чтобы было совершенно ясно, какие отношения существуют в этой таблице.

У каждого есть родитель.Не у всех есть дети.У некоторых родителей родители не указаны в этой базе данных;они «лучшие родители».

Проще всего, если у верхних родителей есть строки в мосту родитель-потомок с родительским FK, равным NULL.Таким образом, вы избегаете сверхсложных внешних соединений - у каждого члена есть хотя бы одна строка-родитель;в идеале два.

Вы обнаружите множество «циклических» проблем, поскольку отношения транзитивны.

Обратите внимание, что вы не можете — с помощью одного стандартного SQL-запроса — найти всех членов семьи, или всех родителей вплоть до верхней части семьи, или всех детей и внуков.Существуют расширения SQL, которые делают это возможным, но стандарт с этим не справляется.

Каскадное удаление не работает, поскольку отношения в семье направлены двумя способами (от родителя к детям, от ребенка к родителям), но SQL имеет только один тип направления (ссылка FK).

Вы можете попытаться гарантировать, что каждый член ДОЛЖЕН иметь хотя бы одну (и не более двух) строк в «member-parent». и удаление члена удаляет две строки в «member-parent» и у клавиш есть собственные имена, вы можете выполнить часть этой работы.

Обратите внимание: когда вы удаляете участника, это нарушает его родительские отношения.Вы удаляете строку-родитель-член.Это хорошо.А как насчет их детей?Другие строки, в которых элемент-родитель ссылается на этого удаленного родителя, теперь разбиты.Что это значит?То, что должно быть сделано?

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

Поскольку SQL не справляется с этой задачей, все проекты будут иметь проблемы.

Answer 2

1. Предполагая, что у каждого члена может быть только одна мать и один отец, вы сможете получить все отношения, просто сохранив mother_id и father_id поле в members стол.

   Однако это будет работать только в том случае, если ваша база данных не будет имеют недостающую информацию.Например, если участник X является братом участника Y, узнать это невозможно, если только родители X и Y не сохранены в базе данных.

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

2. А member_member У предложенного вами моста есть одна серьезная проблема, поскольку он подразумевает направление отношений, так что, если X является отцом Y, Y также является сыном X.Вы предложили определять отношения дважды в обе стороны, но в целом это не рекомендуется.Это форма дублирования данных, и вам может быть сложно обеспечить ссылочную целостность при дублировании данных.Помните, что СУБД не знает, что X является отцом Y, то же самое, что Y является сыном X.

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