Дизайн базы данных - использовать FK или отдельную таблицу?

Question

Скажем, у меня есть таблица с именем 'A'. Таблица «A» может иметь отношение 1: 0 или 1: 1 к таблице «B». Около 95% строк в таблице «A» не будет иметь ссылки на какие-либо строки в таблице «B».

Итак, я мог бы сделать это двумя разными способами.

1

В таблице 'A' у меня может быть столбец FK для таблицы 'B'. Однако примерно 95% строк будут содержать значение NULL в этом столбце FK.

2

Я мог бы создать таблицу «C», которая содержит столбец FK для таблицы «A» и столбец FK для таблицы «B». Затем я бы добавил строку к таблице «С» только в 5% случаев, когда у меня есть связь между таблицами «А» и «В».

Следует также упомянуть, что строка в таблице «B» может указывать на множество строк в таблице «A».

Какой способ решения этой проблемы предпочтительнее?

Answer 1

Я бы не рекомендовал первый.

Вместо этого я бы рекомендовал, чтобы таблица B содержала FK для таблицы A, тогда около 5% строк в B будут содержать NULL, если отношения не применяются.

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

Answer 2

Обновление: у вас есть N: 0..1 (отличается от 1: 0..1). В этом случае ваши 2 решения являются единственно возможными. На практике это, вероятно, зависит от того, какой случай вы хотите оптимизировать; Я бы пошел для простоты на один столик меньше.

Обычно простота решения 1 делает его предпочтительным. Вы можете легко выполнять объединения с таблицей B и фильтровать по NULL / NOT NULL без объединений.

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

РЕДАКТИРОВАТЬ: ЭТОТ ПАРАГРАФ НЕДОСТУПЕН: Вам не хватает другого возможного решения. Иметь внешний ключ в B, указывающий на A. Из того, что вы говорите в своем вопросе, кажется, что каждая запись в B должна иметь запись в A. Следовательно, вы можете указать от B до первичного ключа в A, и не будет пустые записи в любой таблице. Конечно, вы теряете возможность проверять записи в A без соответствующего B без объединения.

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