Чи є вагомі причини для збереження дати та часу в окремих колонках?

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

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

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

Чи розділення дати та часу є поганою практикою чи є щось дуже блискуче в цьому дизайні, я не розумію?

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

Це означає, що немає нічого блискучого в розділенні дати та часу, тому нічого не вистачає.

(Інший варіант полягає в тому, що розробники вашої системи ERP не знали, що в полі дати можна зберігати дату і час, але набагато більше шансів на те, що вони мали вимогу бізнесу, щоб він працював так само, як і попередні версії.)

Як правило, це залежить від використання. Якщо багато запитів об'єднуються разом з піделементами, тоді замість цього потрібно зберігати їх разом, а потім взяти на себе накладні витрати, щоб розбити їх на більш рідкісні випадки. Звичайно, розщеплення іноді складніше (або неможливо): розгляньте person_full_nameатрибут, з якого вам потрібно витягнути person_family_name. Однак, тимчасове значення внизу є тривіальним, тому я, як правило, вважаю за краще зберігати дату та час разом.

Також розглядайте можливість зберігання як І разом, так і з обмеженнями (а може бути і тригерами), щоб переконатися, що вони не виходять із синхронізації: таким чином ви берете на себе поділ / з'єднання в точці оновлення, а не під час запитів на дані.

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

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

Щоб додати коментар ConcernedOfTunbridgeWe, є перевага в виконанні запитів, якщо у вас є таблиця DateDimension та таблиця TimeDimension. Розглянемо, у таблиці фактів є і датаDimensionKey, і TimeDimensionKey. Якщо ви хочете знайти кількість чогось між 8 ранку до 17 вечора, ви можете просто зробити

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

Можливо, для цього потрібно сканувати таблицю, оскільки двигун бази даних повинен обчислювати результат для кожного ряду, перш ніж він зможе з'ясувати, які дані можуть бути повернуті.