Циклические зависимости во внешних ключах: использовать его или избегать?

Question

Мое приложение загружает большое количество данных из базы данных в сложную структуру данных. В памяти структуры данных ressembles структуру базы данных, что означает, что, если база данных содержит следующие таблицы:

• таблицу А, ключ А1
• таблицу В, ключ В1, один из столбцов является внешним ключом к [ключу] таблицы А,
• таблицы C, ключ представл ет собой C1, один из столбцов является внешним ключом к [ключу] таблица B

Тогда у меня есть классы A, B и C и:

• член данных B (B) :: m_a является указателем на
• член данных C (C :: M_B) представляет собой указатель на B

Это означает, что если загрузить базы данных, что я должен загрузить его в правильном порядке. Если я сначала загружу C, он будет жаловаться, что он не может установить значение C :: m_b, потому что экземпляр, в котором он должен указывать, не был загружен.

Проблема заключается в том, когда есть также столбец А, что является внешним ключом к одной из других таблиц, скажем C.

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

Прочитав о хорошем дизайне (например, в книге «Масштаб C++ Software Design»), мне кажется, что плохая идея иметь круговые ссылки вообще. . если файл X.H включает Y.H, но Y.H также включает X.H, у вас, вероятно, плохой дизайн; если класс X зависит от класса Y, и наоборот, у вас, вероятно, есть плохая конструкция, которая должна быть решена путем извлечения этой зависимости и введения третьего класса Z, который зависит от X и Y (X и Y больше не будут зависеть от eachother) ,

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

Answer 1

Единственный раз, когда вам нужна круговая ссылка, вы создаете иерархическую структуру, такую ​​как организационное дерево.

Table Employees 
    EmployeeID <----------| 
    SupervisorEmployeeID ---| 

Answer 2

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

Answer 3

С точки зрения моделирования данных нет ничего принципиально «неправильного» с зависимостью circualr. Это не значит, что модель ошибочна.

К сожалению, большинство СУБД SQL не могут эффективно реализовать такие ограничения, поскольку они не поддерживают несколько обновлений таблиц. Обычно единственный способ - временно приостановить одно или несколько ограничений (например, используя «отложенный» внешний ключ или аналогичные функции) или путем изменения модели, чтобы сделать некоторую часть ограничения необязательной (помещая один из ссылочных столбцов в новая таблица). Это всего лишь обходной путь для неприятного ограничения SQL, но это не значит, что вы сделали что-то не так, чтобы начать.

Answer 4

Вы должны смоделировать данные, которые у вас есть.Если в данных есть круговая взаимосвязь (например, каждая фотография принадлежит папке, но в каждой папке есть одна фотография обложки), то правильно ее моделировать как круговое отношение в базе данных.

У меня была такая ситуация только один раз при использовании Oracle, поэтому у меня не было возможности проверить, как реализовать такие отношения в других базах данных. Но для Oracle вы можете прочитать мою статью здесь:

http://www.databasesandlife.com/circular-dependencies-on-foreign-key-constraints-oracle/