datetime2 (0) против datetime2 (2)

Согласно документации datetime2 (Transact-SQL) :

Размер хранилища
6 байтов для точности меньше 3.
7 байтов для точности 3 и 4.
Все остальные точности требуют 8 байтов.

Размер datetime2(0), datetime2(1), datetime2(2)использовать один и тот же объем памяти (6 байт).

Буду ли я прав, говоря, что я мог бы также пойти datetime2(2)на пользу и получить выгоду от точности без каких-либо дополнительных затрат размера?

Пожалуйста, обратите внимание:

• Этот столбец индексируется с помощью PK для формирования составного кластерного индекса (используется для разделения таблиц)
• Мне плевать на миллисекунды

Будет datetime2(0)ли процессор более эффективен при использовании в предложении where или при поиске по индексу?

Это массивная таблица, поэтому наименьшая оптимизация будет иметь большое значение.

Размеры dateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3) используют одинаковый объем памяти. (6 байт)

Буду ли я прав, говоря, что я мог бы также пойти с dateTime2 (3) и получить преимущество точности без каких-либо дополнительных затрат на размер.

Нет, вы неверно истолковали документацию. Обратите внимание, что объем хранения документов в документообороте составляет 6 байт для точности менее 3 (выделено). Таким образом, точность, равная 3, потребует 7 байтов.

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

Требования к приложениям определяют, что должно храниться в базе данных, когда в источнике доступна более высокая точность. Например, для времени ввода заказа, полученного от SYSDATETIME(), пользователи могут не захотеть точность до 100 наносекунд. Опять же, выберите тип данных и точность для новой разработки в соответствии с требованиями, и вы, как правило, получите оптимальную производительность без дополнительных размышлений:

• дата - тебе не нужно время
• smalldatetime - вам не нужны секунды
• datetime2 (0) - вам не нужны доли секунды
• datetime2 (1-7) - вам нужны доли секунды указанной точности
• datetimeoffset (0-7) - вам нужны дата и время с учетом часового пояса
• время (0-7) - вам нужно только время (без даты) с долями секунды указанной точности

Хотя datetime2 наиболее подходит для новой разработки, как указано выше, иногда может потребоваться использовать datetime (с фиксированной точностью 3 с точностью до 1/300 долей секунды) вместо этого для совместимости с унаследованными приложениями datetime, что позволяет избежать неявных преобразований и непредвиденного поведения сравнения, но при за счет дробной секундной точности и увеличенного хранения.

Учтите, что хранение с большей точностью, чем требуется, может также иметь стоимость разработки. Если хранить компонент времени с долями секунды, когда требуется только точность в целую секунду, запросам все равно придется учитывать доли секунды, чтобы вернуть правильные результаты. Например, в приложении, в котором пользователь выбирает временной интервал с помощью пользовательского интерфейса, который допускает только целые секунды, код приложения должен будет учитывать доли секунды в значении конечного временного диапазона и соответствующим образом корректировать предоставленное пользователем значение (например, WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'или WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'). Это добавит сложности кода.