Есть ли веские причины хранить дату и время в отдельных столбцах?

Я пытаюсь понять решение нашего поставщика программного обеспечения сохранить дату и время в отдельных столбцах. Например, когда строка была создана или обновлена. Время и дата являются столбцами DateTime. Мы используем SQL Server 2005.

База данных содержит данные нашей системы ERP, и я считаю, что самые большие таблицы содержат около 3 миллионов строк. Большинство таблиц находятся примерно между 100 000 - 1 000 000 строк.

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

Разделяет дату и время плохую практику или в этом дизайне есть что-то очень блестящее, я не понимаю?

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

Тем не менее, нет ничего блестящего в разделении даты и времени, поэтому вы ничего не пропустите.

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

Как правило, это зависит от использования. Если многие запросы объединяют подэлементы, рассмотрите вместо этого их хранение вместе, а затем возьмите на себя необходимость разделить их на части в тех редких случаях. Конечно, разбиение иногда бывает более сложным (или невозможным): рассмотрите person_full_nameатрибут, из которого вам нужно извлечь person_family_name. Тем не менее, приведение к временному значению тривиально, поэтому я бы предпочел хранить дату и время вместе.

Также рассмотрите возможность хранения как вместе, так и отдельно, с ограничениями (и, возможно, триггерами), чтобы гарантировать, что они не синхронизируются: таким образом, вы получаете удар разделения / объединения в точке обновления, а не во время запроса данные.

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

Вы также можете представить дату и время в виде вычисляемых столбцов на основе основного столбца datetime.

Чтобы добавить к комментарию ConcernedOfTunbridgeWe, есть преимущество в производительности запроса, если у вас есть DateDimension и таблица TimeDimension. Представьте, что таблица фактов имеет как dateDimensionKey, так и TimeDimensionKey. Если вы хотите найти номер чего-то с 8 утра до 5 вечера, вы можете просто сделать

SELECT COUNT(1) FROM FactTable f Inner Join TimeDimension t on f.TimeDimensionKey = t.TimeDimension WHERE t.Hour BETWEEN 8 AND 17.

Если у вас есть индекс, добавленный к TimeDimensionKey, вам понадобится только поиск индекса для результата в таблице фактов для поиска данных

Без таблицы TimeDimension вам придется сделать что-то вроде следующего,

SELECT COUNT(1) FROM FactTable f WHERE DatePart(mintue, f.Date) BETWEEN 8 AND 17

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