Должен ли я объединить эти таблицы базы данных.

Question

У меня есть приложение календаря событий с базой данных sql, и сейчас у меня есть 3 таблицы для представления событий:

Таблица 1: Праздник
Столбцы: ID, Дата, Имя, Местоположение, CalendarID

Таблица 2: Отпуск
Столбцы: Id, Дата, Имя, PersonId, WorkflowStatus

Таблица 3: Событие
Столбцы: Id, Date, Name, CalendarID

Итак, у меня есть «общие события», которые входят в таблицу событий, и специальные события, такие как праздники и каникулы, которые входят в эти отдельные таблицы. Я обсуждаю объединение их в одну таблицу и просто наличие столбцов, таких как location и personid, для общих событий.

Таблица 1: Событие:
Столбцы: Id, Дата, Имя, Местоположение, PersonId, WorkflowStatus

Кто-нибудь видит какие-либо сильные или отрицательные стороны каждого варианта? Очевидно, что будут записи, в которых есть столбцы, которые необязательно применяются, но эти три таблицы перекрываются.

Answer 1

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

Другая проблема заключается в том, что это те события, которые вам нужны сейчас, и в будущем может появиться все больше и больше специализированных событий, и, возможно, нарушение кода для одного типа события, поскольку вы добавили другое специализированное поле, которое применяется только к чему-то другому, является большим риск. Когда вы вносите изменения, чтобы добавить некоторую необходимую информацию об отпуске, вы будете уверены, что убедитесь, что она не нарушает заявление о праздниках? Или хуже, не ошибка, но показать информацию, которую вы не хотели? Собираетесь ли вы смотреть на фактический экран каждый раз? Модульное тестирование только кода может не поднять этот тип вещей, особенно если кто-то был достаточно глуп, чтобы использовать select *, или не смог указать столбцы во вставке. И, честно говоря, не в каждой организации действительно есть действительно тщательный автоматизированный процесс тестирования (это может быть меньше риска, если вы это сделаете).

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

Answer 2

Как насчет подтипа специальных событий для Event супертипа?Таким образом, позже можно легко добавлять любые новые специальные события.

Answer 3

В любом случае, приложение должно работать с типами вариантов. В такой ситуации я рекомендую использовать одно представление в DBM, поскольку альтернативой является требование множества запросов.

Таким образом, возникает вопрос о том, где вы придерживаетесь сложности, и даже в огромной организации действительно сложно генерировать достаточно событий, чтобы беспокоиться об оптимизации СУБД. Код приложения является более гибким, чем встроенные схемы. Это вопрос предпочтения.

Answer 4

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

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

Answer 5

Или объедините общие поля и выделите уникальные:

Таблица 1: EventCommon

Столбцы: EventCommonID, Дата, Имя

Таблица 2: EventOrHoliday

Столбцы: EventCommonID, CalendarID, isHoliday

Таблица 3: Отпуск

Столбцы: EventCommonID, PersonId, WorkflowStatus

с 1-> многими связями между EventCommon и другими 2.

Answer 6

Храните их в 3 отдельных таблицах и сделайте UNION ALL в представлении, если вам нужно объединить данные в один набор результатов для потребления. То, как вы храните данные на диске, не обязательно должно совпадать с тем, как вам нужно использовать данные, если производительность достаточна.

Как у вас есть сейчас, нет столбцов, которые не применяются ни к одной из представленных сущностей. Если бы вам пришлось объединить 3 таблицы в одну, вам нужно было бы как минимум добавить поле, чтобы знать, какие столбцы следует заполнить, и снизить производительность. Теперь, когда вы запрашиваете только один выходной, вы переходите к подмножеству данных, которые вам нужно будет просмотреть / index, чтобы получить те же данные в объединенной таблице хранения.

Если вы еще не определили эти таблицы, вы можете создать одну таблицу со следующей подписью ...

create table EventBase (
  Id int PRIMARY KEY,
  Date date,
  Name varchar(50)
)

... и, скажем, праздничный стол со следующей подписью.

create table holiday (
  Id int PRIMARY KEY,
  EventId int,
  Location varchar(50),
  CalendarId int
)

... и присоединяйтесь к ним, когда вам нужно это сделать. Выбор между этой и 3-мя отдельными таблицами, которые у вас уже есть, зависит от того, как вы планируете использовать таблицы и объем, но я бы определенно не бросил все в одну таблицу как есть и сделал бы вещи менее понятными для того, кто смотрит на определение таблицы без других инициация.