Один столбец таблицы для многих таблиц FK? - PullRequest
Новая
       30

Один столбец таблицы для многих таблиц FK?

2 голосов
/ 06 апреля 2011

Каково лучшее решение / практика для такой ситуации? У меня есть таблица, которая может ссылаться на несколько таблиц (объектов)?

Вот пример для таблицы UserCalendar. Это таблица, в которой пользователь сохраняет свое событие, а также системные вставки в эту таблицу сзади. Пользователь выполняет некоторые сервисы, которые имеют крайние сроки и которые также включены в эту таблицу. Проблема в том, что нет такой таблицы, как таблица UserEvent. Пользователь должен сохранить все свои события в этом календаре в качестве описания. Я должен сделать это как можно проще.

Я могу придумать это двумя способами.

1)

UserCalendar
UserCalendarId | UserId | Описание | ObjectType | ObjectId

Используя эту опцию, мне не пришлось бы FK этой таблицы. Я мог только изменить ObjectType (Уведомление, Сервис, Календарь) и использовать идентификатор этой таблицы в качестве ObjectId. В случае события такой таблицы не будет, и это будет нулевое поле. Мы называем этот псевдо FK столбец.

2) Или я мог бы использовать, как сказано в теории, несколько таблиц для каждого FK.

UserCalendar
UserCalendarId | UserId | Описание

UserEvent
UserCalendarId | EventId

UserServices
UserCalendarId | ServiceId

Уведомления пользователей
UserCalendarId | NotificationId
...

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

Первое решение - это быстрое внедрение.

1 Ответ

2 голосов
/ 06 апреля 2011

Я бы предпочел третье решение как сочетание двух ваших дизайнов:

UserCalendar
UserCalendarId |UserId |Описание

UserCalendarAttributes
UserCalendarId |ObjectType |ObjectId

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

Также немного зависит от того, как часто вам нужно обращаться к этим дополнительным данным (событиям, сервису и т. д.), если имеет смысл поместитьFK в вашей основной UserCalendar таблице.

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

...