Циклическая ссылка в таблице базы данных

Question

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

Представьте себе таблицу BANK, в которой содержатся сведения о управляющем банке или обычном банке, который управляет сельскими филиалами, или сельские филиалы, действующие в рамках этого банка, или филиалы розничных банков, которые не попадают в эту иерархию, а только осуществляют операции с сельскими ветка.

Раньше я решил иметь для них 4 разные таблицы с ограничениями FK (т.е. по одной для управляющего банка, банка, в котором работают сельские филиалы, сельского филиала и филиала розничного банка). Но когда я перешел к созданию таблицы TRANSACTION, я был озадачен, поскольку транзакции могли происходить между любыми из этих объектов (например: между сельским филиалом и розничным филиалом, между самими сельскими филиалами и т. Д.). Это означало, что мне нужно было бы не только вести учет идентификаторов «источника» и «места назначения» банковского субъекта, но и сохранять некоторые данные, чтобы помочь логике приложения определить, к какой ТАБЛИЦЕ присоединиться для выполнения запросов. плохо.

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

Поэтому я создал одну таблицу BANK (в основном потому, что они являются похожими объектами, поскольку они могут взаимодействовать друг с другом). Я добавил в таблицу столбец PARENT, в котором будет храниться значение идентификатора родительского учреждения (отношения, которые в противном случае я достиг, используя FK). Таким образом, сельское отделение будет иметь идентификатор операционного банка в родительской колонке. Розничные филиалы не имеют родителей, поэтому там значение равно NULL и т. Д.

Проблема, которую я вижу сейчас, заключается в том, что в таблице BANK есть отношение PK / FK, циклическая ссылка.

Мой вопрос: насколько это плохо? И какой может быть выход?

Answer 1

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

• См. эту статью о выполнении иерархических запросов с использованием Общих табличных выражений .
• См. в этой статье MySQL , подробно описывающей некоторые запросы, используемые в самореференциальных отношениях.

Кроме того, могу ли я порекомендовать вам иметь эту таблицу банков, но сохранить вторичные таблицы для типов банков таким образом, чтобы каждый банк имел запись в таблице банков, и дополнительно имел бы запись в одной из других таблиц, содержащих специфические расширенные свойства типа банка. Таким образом, отношения по-прежнему будут централизованы, пользователи будут по-прежнему привязаны к таблице «Банк» с помощью одного FK, но таблица «Банк» не будет иметь дополнительных свойств для всех типов банков.