sql замкнутые отношения; что может пойти не так?

Question

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

Edit: прошел через мои книги, нашел то, что я читал было Начало проектирования баз данных От новичка до профессионального, издатель: Apress.
они просто предупреждают об этом, но дают неопределенную причину. Нет, мы не используем триггеры. У кого-то есть более четкое объяснение?
Благодаря Выдержки, стр.109:

Небольшая компания имеет сотрудников, каждый из которых для одного из целого ряда различных небольших проектных групп. Каждая группа и всех ее сотрудники размещены в одном конкретного помещения с большими комнатами корпусом несколько groups.We может потребовать информации, таких как, где каждый сотрудник находится, номер телефона конкретного сотрудника, где найти конкретной группу , сотрудники которого работают в каждой группе, кто находится в каждом номере , и так далее. Одна возможная информация показана на рисунке 5-7. Возьмите момент, чтобы понять модель данных и информацию о нем количество групп в комнате и так для этой конкретной проблемы. Модель имеет избыточную информацию. Может вы видите, что это такое?

В отношении примера 5-3, если мы регулярно хотите найти номер телефона сотрудника, мы могли бы думать, что верх отношения на рисунке 5-7 между Employee и номер будет полезным прямым маршрутом. Однако эта же информация очень легко доступна по альтернативному маршруту через группу. Мы можем найти группу сотрудников (только одну) , а затем найти номер этой группы (только один номер ). Это очень простой поиск (это не связано со всеми осложнениями с датами, которые преследовали небольшое общежитие в примере 5-2). Однако дополнительные отношения не являются просто лишним, это опасно. С двумя маршрутами для тех же информации, мы рискуем получить два ответа , если только данные очень тщательно сохранены. Всякий раз, когда сотрудник меняет группу или группу сменяет номера, для обновления потребуется два экземпляра отношений . Без очень осторожны обновлениями процедур, мы могли бы в конечном итоге, , что Джим находится в группе А, которая находится в номере 12, в то время как другой маршрут может у Джима связан непосредственно с номером 15. Избыточной информации склонна к несоответствиям и всегда должен быть удален .

Answer 1

У меня не было проблем в прошлом с использованием ссылок «замкнутого цикла» между группами таблиц (т. Е. Не менее 3 в цикле отношений). Единственная проблема, о которой я могу думать, - это использовать триггеры, и даже тогда это будет проблемой только в том случае, если вы обновляете другие таблицы в «цикле» в триггере.

У вас есть ссылка на то, где вы читаете этот совет за отсутствие замкнутых петель?

Остальным, кто комментировал изображение можно увидеть, если скопировать ссылку в новом окне: http://imgur.com/ChFL1

Answer 2

Не все базы данных отложили отношения проверка включена и не все базы данных позволяют вставлять две записи в двух разных таблиц одно заявление.

Представьте, что вы есть FOREIGN KEY от A к B и от B к A.

Первоначально обе таблицы пусты.

Как вы собираетесь вставить самую первую запись?

Вы ничего не можете вставить в A, так как он должен ссылаться на запись в B (что пусто), и точно так же вы не можете вставить ничего в B.

Answer 3

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

Пример текстовой книги кажется мне совершенно понятным. Есть 2 способа, в которых/можно определить телефон работника местоположение:

• Служащий -> Группа -> номер -> Телефон
• или сотрудников -> номер -> Телефон

Это похоже на сохранение двух переменных для одной и той же вещи, которые необходимо синхронизировать. Будет вероятность того, что что-то пойдет не так, и переменные в конечном итоге будут иметь разные значения, - тогда вы должны спросить: «Какое из двух правильных?»

Таким образом, в примере с текстовой книгой подчеркивается проблема, с которой вы должны смотреть наши. Однако проблема действительно сводится к семантике. То есть что означают отношения. В примере с текстовой книгой оба пути к Room означают то же самое. Если, однако, Group -> Room были просто «дефолтом» для каждого сотрудника, потому что старшие сотрудники могли получить свою комнату, или сотрудники могли временно назначаться на работу где-то вдали от своей группы, тогда дополнительные отношения были бы оправданы.

Двигаясь на ваш дизайн, это то, что вы должны сделать:

• Look для закрытых групп
• Оценивать семантика/назначение/значение отношений
• Убедитесь, что вы не только что создали два пути к одному и тому же информация.

Например, у вас есть:

• TestSample -> Coil -> Slab
• TestSample -> Тарелка -> Slab

(Простите, возможно, абсурдные понимание ваших терминология.) Означает ли это, что ваш тестовый образец может быть на двух разных плитах одновременно? Или это означает, что ваш тестовый образец будет состоять из пластины и катушки, которая могла бы (но не обязательно) исходить из разных плит?