Дизайн базы данных: одна таблица против трех таблиц

Question

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

• У меня должна быть одна таблица, в которой будет поле для уникальной идентификации каждого объекта (компании, отдела, пользователя), и в зависимости от того, кто запрашивает, я могу получить результаты соответственно
• У меня должно быть несколько таблиц.Одна таблица для компании, Одна таблица для отделов, Одна таблица для пользователей.

Таким образом, это больше похоже на наличие одной таблицы на три таблицы.

Answer 1

Я не думаю, что события должны знать, принадлежат ли они компании, отделу пользователя напрямую.Я подозреваю, что события принадлежат календарю, а календарь принадлежит компании, отделу или пользователю?

Итак, таблица календаря:

CALENDAR_ID

А затем таблица событий

EVENT_ID

И таблица «EVENT_TO_CALENDAR» (для целей отношения многие ко многим:

CALENDAR_ID
EVENT_ID

Если пользователь может видеть событие в календаре компании, он может сказать «добавить его вмоя », которая создаст новую запись в таблице EVENT_TO_CALENDAR с тем же EVENT_ID, но с уникальным CALENDAR_ID. Теперь событие связано с каждым календарем (компанией и пользователем).

Answer 2

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

Answer 3

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