Круговые зависимости во внешних ключах: использовать это или избегать?

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

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

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

элемент данных B (B :: m_a) является указателем на Aэлемент данных C (C :: m_b) является указателем на B

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

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

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

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

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

Ответы на вопрос(4)

Ваш ответ на вопрос