Дизайн базы данных SQL

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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