Вопрос проектирования базы данных

Question

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

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

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

Благодаря

Answer 1

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

Answer 2

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

Так Календарь настольный:

CALENDAR_ID 

И тогда таблица

EVENT_ID 

событием и "EVENT_TO_CALENDAR" таблица (для целей многие ко многим отношений:

CALENDAR_ID 
EVENT_ID 

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

Answer 3

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