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

Question

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

Редактировать:просмотрел свои электронные книги, обнаружил, что то, что я читал, было Начало разработки базы данных От новичка до профессионала, издатель:АПРЕЛЬ.
они просто предостерегают от этого, но дают расплывчатую причину почему.Нет, мы не используем триггеры.У кого-нибудь есть более четкое объяснение?
Спасибо Отрывок, стр.109:

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

Что касается примера 5-3, если мы регулярно хотим найти номер телефона сотрудника , мы могли бы подумать, что связь top на рисунке 5-7 между Сотрудником и помещением была бы полезной прямой маршрут.Однако это то же самое информация очень легко доступна альтернативным путем через группу.Мы можем найти (только одну) группу сотрудника , а затем найти комнату этой группы (только одну ).Это очень простой поиск (он не включает в себя все сложности с датами, которые преследовали небольшой хостел в примере 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 если бы это было просто "по умолчанию" для каждого сотрудника, потому что старшие сотрудники могли бы получить свою отдельную комнату или сотрудников можно было бы временно перевести на работу в другое место, подальше от их группы, тогда дополнительные отношения были бы оправданы.

Переходя к вашему дизайну, это то, что вы должны сделать:

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

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

• Тестовый образец -> Катушка -> Плита
• Тестовый образец -> Плита -> Сляб

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