Дизайн базы данных один ко многим, где много, по крайней мере, один

Question

Отчасти связанный с моим предыдущим вопросом , это касается шаблонов создания для применения шаблонов таблиц, где «A» имеет много дочерних элементов «B», где «C» - таблица дочерних «B» для «A» , но имеет по крайней мере ОДИН.

В настоящее время у меня есть:

A (A_ID primary key, B_ID reference key)
B (B_ID primary key, etc)
C (A_ID reference, B_ID reference)

Дело в том, что A определенно всегда имеет, по крайней мере, ОДИН «B» «потомок», но, возможно, намного больше… однако проблема, с которой я столкнулся, состоит в том, что таблица «C» может в настоящее время ссылаться на тот же «B», что и «A» Это уже косвенные ссылки ..

пример:

A
- Id: 1
- B_Id: 37

C
- A_Id: 1
- B_Id: 37

Какой лучший способ ограничить это? отмечая, что «A» можно обновить, чтобы попытаться сослаться на «B», который уже указан в коллекции «C» для этого «A», и, более вероятно, «C» ссылается на «B», который уже косвенно указан связанный «А» ..

Надеюсь, что это имеет смысл, и снова приветствует заранее.

Редактировать: таблицы следующие:

«A» - это представление, в представлении может быть много «участников» (участников), но всегда как минимум один. 'B' является участником «C» - это таблица, которая связывает «А со многими» В

Answer 1

Перевод вашей абстрактной схемы в конкретную схему, я думаю, выглядит примерно так:

• Представление (SubmissionID, PrimaryContributorID, ...)
• Contributor (ContributorID, ...)
• SubmissionContributors (SubmissionID, ContributorID)

Это может дать вам «хотя бы одного» участника для каждого представления, но это означает наличие некоторых нечетных / сложных правил для обеспечения исполнения. Сложность возникает из-за PrimaryContributorID. Соответствующая запись существует в таблице SubmissionContributors? Если PrimaryContributor изменится, нужно ли переставлять записи в SubmissionContributors? Если у PrimaryContributor нет соответствующей записи SubmissionContributor, каждый раз, когда вы вносите список участников для представления, вы должны объединиться в PrimaryContributor и т. Д.

К сожалению, в SQL нет отношения «по крайней мере, один ко многим» (о чем я вообще не знаю :)), поэтому любое решение, которое вы придумаете, будет включать некоторый компромисс.

Для меня лучшим подходом было бы удалить PrimaryContributorID; Все участники существуют в таблице SubmissionContributors, и у вас будет логика домена, которая обеспечивает выполнение «как минимум одной» части требований (например, методы, которые вставляют / обновляют записи отправки, завершатся неудачно, если нет хотя бы одного участника, и методы что чтение записей отправки завершится неудачей, если не будет хотя бы одного участника).

Answer 2

Я не думаю, что когда-либо будет случай, когда вы захотите / должны содержать ссылку в двух отдельных областях.

Кроме того, вы хотите иметь ссылку на многие отношения один ко многим. Если для A есть 1+ B, то таблица B должна содержать ссылку A, а не наоборот.

Если C нужно вернуть B, которые есть у A, просто сделайте C хранимой процедурой или представлением, которое соединяет таблицу A и B, таким образом, данные никогда не будут синхронизированы.

Answer 3

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