Трехуровневая база данных - внешние ключи

Question

У меня есть трехуровневая база данных со следующей структурой (упрощенная для отображения только первичных ключей):

Table A: a_id
Table B: a_id, b_id
Table C: a_id, b_id, c_id

Таким образом, возможные значения для таблицы C будут примерно такими:

a_id  b_id  c_id
   1     1     1
   1     1     2
   1     1     3
   1     2     1
   1     2     2
   2     1     1
   2     2     1
   2     2     2
...

Теперь я не уверен, как следует устанавливать внешние ключи; или если они должны быть установлены для первичных ключей вообще. Моя идея состояла в том, чтобы иметь внешний ключ в таблице B B.a_id -> A.a_id и два внешних ключа в C C.a_id -> A.a_id и ( C.a_id, C.b_id ) -> ( B.a_id, B.b_id ).

.

Так я должен настроить внешние ключи? Нужен ли внешний ключ от C->A? Или мне вообще нужны внешние ключи, учитывая, что все эти столбцы являются частью первичных ключей?

Спасибо.

Answer 1

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

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

Таблица A: a_id (pk)
Таблица B: b_id (pk), a_id (fk)
Таблица C: c_id (pk), b_id (fk)

Вам не нужен внешний ключ между таблицей C и таблицей A, потому что эта связь подразумевается внешними ключами между таблицей C и таблицей B, а также таблицей B и таблицей A.

1012 * редактировать *

Что плохого в использовании соединения первичные ключи?

При присоединении таблицы C к таблице B. вводится на одну строку меньше. Кроме того, количество столбцов накапливается при распространении внешних ключей, поэтому в таблице D составной первичный ключ будет состоять из четырех столбцов. В какой-то момент это начинает чувствовать себя глупо. Однажды я работал в системе, в которой была таблица J с девятью столбцами первичного ключа и двумя столбцами данных.

Другое дело, составные ключи также могут быть связаны с бизнес-ключами. Распространение их как внешних ключей может быть настоящей болью в шее. После того, как мы приняли решение использовать суррогатные (синтетические) ключи для одной таблицы - автоинкремент, последовательность, guid, что угодно - согласованность предполагает, что мы должны использовать один и тот же механизм для первичных ключей во всех наших таблицах.

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

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

select D.* 
from  D 
    join A on ( D.a_id = A.id )
where A.some_col = 'whatever'

Отсутствие необходимости соединять Таблицу D с Таблицей C с Таблицей B, чтобы попасть в Таблицу A, было определенным благом. Это было бы еще более справедливо для баз данных, реализующих Виртуальную частную базу данных, когда он должен ограничить доступ ко всем нашим таблицам на основе того, что пользователи имеют доступ к подмножеству буксировок в таблице А.

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

Короче говоря, составные первичные ключи не являются неправильными просто громоздкими. Один столбец, суррогатные первичные ключи, вероятно, являются отраслевым стандартом. Однако в некоторых ситуациях составные первичные ключи являются правильным выбором.

Answer 2

Если у вас уже есть внешний ключ между таблицей B и таблицей A, чтобы убедиться, что таблица B содержит только записи, имеющие значение для a_id, существующее в таблице A, то дополнительный FK между таблицей C и таблицей A в a_id не нужно. Это, конечно, требует, чтобы отношение FK между таблицей B и таблицей A было принудительным, активным и не было отключено или каким-либо образом обойдено.

Установление связи FK между таблицей C и таблицей B уже гарантирует, что TableC.a_id может ссылаться только на действительное значение a_id (поскольку это гарантировано в таблице B через отношение FK между таблицей B и таблицей A).