SQL Server Datetime против производительности ключа Int

Question

Для вас гуру дизайна / производительности базы данных.

Если у вас есть база данных, предназначенная для отслеживания финансовых данных за периоды финансового года, лучше / лучше производительность / понятнее выполнять поиск по типу дат, например PaymentDate между X и Y, или лучше сохранять инт-ключ на основе таблицы с определенными в ней периодами финансового года и пометьте таблицу платежей датой платежа и этим ключом, поэтому предложение where - это где FiscalPeriodID = X?

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

Answer 1

Я ежедневно работаю со складами в миллионах рядов, и мы находим, что умные ключи даты - это путь. Это в формате ГГГГММДД. Таким образом, чтобы найти весь 2008 год, вы должны сделать:

select
    *
from
    gl
where
    postdate between 20080101 and 20081231

С индексированным столбцом это феноменально быстро, даже для одного миллиарда строк. Это также указывает на таблицу дат, поэтому мы можем указать день недели, названия месяцев или любую другую информацию о датах, которые у нас есть с этим объединением.

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

Answer 2

Также обратите внимание на то, что в действительности является частью даты в поле Actual datetime или smalldatetime ... 4-байтовое целое число, представляющее количество дней с 1 января 1900 года.

Это может быть приведено к фактической дате / времени неявно, очень быстро (так как это точно такое же значение, что и первые четыре байта 8-байтового значения DateTime)

вы также можете использовать его в предложениях Where для фактических значений даты и времени, поскольку механизм SQL Server неявно преобразует одно в другое и обратно.

Кроме того, каждое возможное значение 32-разрядного (4-байтового) целого числа является допустимым значением datetime (Midnight) для внутреннего типа данных Datetime внутреннего сервера SQL Server

Answer 3

Если вы можете использовать smalldatetime, он имеет тот же размер, что и целое число - оба 4 байта.А под капотом типы данных datetime - целые числа.

Первые 2 байта smalldatetime - это что-то вроде количества дней, прошедших с 01.01.1900, а вторые 2 байта - что-то вроде количества секунд, прошедших с полуночи.(Возможно, это не совсем точно, но вы понимаете, в чем дело.) Таким образом, эти типы данных очень эффективны.

Я думаю, что предложение where, выполненное для поля smalldatetime, подойдет.

Answer 4

То, что вы в конечном итоге делаете со значительными финансовыми наборами данных, это «кубы данных».

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

Так что это не имеет значения. Однако сохраните его и используйте историческую базу данных, которая будет более эффективной для долгосрочных отчетов.

Я бы пошел с датой, сохраненной непосредственно против записи.