sql замкнутый цикл отношений; что может пойти не так? - PullRequest
2 голосов
/ 11 января 2010

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

schematic of part of our database

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

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

example figure

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

Ответы [ 3 ]

3 голосов
/ 11 января 2010

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

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

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

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

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

1 голос
/ 11 января 2010

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

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

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

0 голосов
/ 22 января 2010

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

Пример из учебника кажется мне вполне понятным.Существует 2 способа определения местоположения / телефона сотрудника:

  • Сотрудник -> Группа -> Комната -> Телефон
  • или Сотрудник -> Комната -> Телефон

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

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

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

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

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

  • TestSample -> Coil -> Slab
  • TestSample -> Plate -> Slab

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

...