Рекомендуемая структура для таблицы с FK для 3 других таблиц - PullRequest
Новая
       4

Рекомендуемая структура для таблицы с FK для 3 других таблиц

1 голос
/ 31 марта 2011

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

Два вопроса:
а) Это лучший дизайн или есть что-то еще более широко распространенное?
b) Какова рекомендуемая процедура, чтобы гарантировать, что идентификаторы действительны для данного типа объектов?

Ответы [ 3 ]

3 голосов
/ 31 марта 2011

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

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

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

  • Три FK не обязательно должны иметь одинаковый тип данных.
  • Синтаксис JOIN становится более естественным (без использования поля типа).
  • Вы можете добавить ограничения ссылочной целостности для этих столбцов FK.
  • Вам не нужно гарантировать правильность поля типа - фактически, вам вообще не нужно поле типа. Тип определяется неявно одним столбцом FK, который не является нулевым.
0 голосов
/ 31 марта 2011

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

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

0 голосов
/ 31 марта 2011

Основы проектирования схемы БД просты, но более сложные ситуации могут быть действительно сложными, чтобы выяснить что лучше .Здесь много личной субъективности, которая может вступить в игру, и даже производительность может стать фактором денормализации дизайна.

Отказ от ответственности, моя личная рекомендация - никогда не использовать столбец для хранения более одного вида FK, т.е. столбец для FK должен хранить FK, которые указывают только на одну таблицу.Если вы этого не сделаете, вы должны отобразить каскад данных этого столбца в несколько запросов на дополнительный выбор внутри вашего кода, и он может стать более запутанным, чем вы ожидали.Ваша заданная «Проблема № 2, гарантирующая валидность между типом и FK» - это всего лишь начало всего мира боли, который будет касаться всего вашего исходного кода.

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

...