DateTime2 против DateTime в SQL Server

Который из:

• datetime
• datetime2

это рекомендуемый способ даты и времени хранения в SQL Server 2008+?

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

В документации MSDN для datetime рекомендуется использовать datetime2 . Вот их рекомендация:

Используйте time, date, datetime2и datetimeoffsetтип данных для новой работы. Эти типы соответствуют стандарту SQL. Они более портативны. time, datetime2И datetimeoffset обеспечивают более секунды точности. datetimeoffsetобеспечивает поддержку часовых поясов для глобально развернутых приложений.

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

DATETIME2имеет диапазон дат от « DATETIME0001/01/01» до «9999/12/31 », в то время как тип поддерживает только год 1753-9999.

Кроме того, если вам нужно, DATETIME2может быть более точным с точки зрения времени; DATETIME ограничен 3 1/3 миллисекундами, но DATETIME2может быть точным до 100 нс.

Оба типа отображаются System.DateTimeв .NET - никакой разницы нет.

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

Плюс: если вам нужна только дата (без временной части), используйте DATE - это так же хорошо, как DATETIME2и экономит ваше место! :-) То же самое касается только времени - используйте TIME. Вот для чего существуют эти типы!

datetime2 выигрывает в большинстве аспектов, кроме (совместимость старых приложений)

1. больший диапазон значений
2. лучшая точность
3. меньший объем памяти (если указана необязательная точность, указанная пользователем)

пожалуйста, обратите внимание на следующие моменты

• Синтаксис
  • datetime2 [(точность долей секунды => выглядит ниже размера хранилища)]
• Точность, масштаб
  • От 0 до 7 цифр с точностью до 100 нс.
  • Точность по умолчанию составляет 7 цифр.
• Размер хранилища
  • 6 байтов для точности менее 3;
  • 7 байтов для точности 3 и 4.
  • Вся остальная точность требует 8 байтов .
• DateTime2 (3) имеет то же количество цифр, что и DateTime, но использует 7 байтов памяти вместо 8 байтов ( SQLHINTS-DateTime против DateTime2 )
• Узнайте больше о datetime2 (статья о MSDN на Transact-SQL)

источник изображения: MCTS Self-Paced Training Kit (экзамен 70-432): Microsoft® SQL Server® 2008 - Внедрение и обслуживание Глава 3. Таблицы -> Урок 1. Создание таблиц -> стр. 66

Я согласен с @marc_s и @Adam_Poward - DateTime2 - предпочтительный метод продвижения вперед. Он имеет более широкий диапазон дат, более высокую точность и использует одинаковое или меньшее хранилище (в зависимости от точности).

Одно обсуждение пропустили, однако ...
@Marc_s заявляет: Both types map to System.DateTime in .NET - no difference there. Это верно, однако обратное неверно ... и это важно при выполнении поиска в диапазоне дат (например, "найди мне все записи, измененные 5/5/2010").

.NET версия Datetimeимеет схожий диапазон и точность DateTime2. При сопоставлении .net Datetimeсо старым SQL DateTimeпроисходит неявное округление . Старый SQL с DateTimeточностью до 3 миллисекунд. Это означает, что 11:59:59.997это как можно ближе к концу дня. Все, что выше, округляется до следующего дня.

Попробуй это :

declare @d1 datetime   = '5/5/2010 23:59:59.999'
declare @d2 datetime2  = '5/5/2010 23:59:59.999'
declare @d3 datetime   = '5/5/2010 23:59:59.997'
select @d1 as 'IAmMay6BecauseOfRounding', @d2 'May5', @d3 'StillMay5Because2msEarlier'

Избежание этого неявного округления является важной причиной для перехода на DateTime2. Неявное округление дат явно вызывает путаницу:

• Странное поведение даты и времени в SQL Server
• http://bytes.com/topic/sql-server/answers/578416-weird-millisecond-part-datetime-data-sql-server-2000-a
• SQL Server 2008 и миллисекунды
• http://improve.dk/archive/2011/06/16/getting-bit-by-datetime-rounding-or-why-235959-999-ltgt.aspx
• http://milesquaretech.com/Blog/post/2011/09/12/DateTime-vs-DateTime2-SQL-is-Rounding-My-999-Milliseconds!.aspx

Почти все ответы и комментарии были тяжелыми для плюсов и легкими минусами. Вот краткий обзор всех плюсов и минусов на данный момент, а также некоторые важные минусы (в # 2 ниже), которые я видел, упоминал только один раз или не упомянул вообще.

1. ПЛЮСЫ:

1.1. Более совместимый с ISO (ISO 8601) (хотя я не знаю, как это проявляется на практике).

1.2. Большой диапазон (с 1/1/0001 по 12/31/9999 по сравнению с 1/1 / 1753-12 / 31/9999) (хотя дополнительный диапазон, все до 1753 года, скорее всего, не будет использоваться, кроме как, в исторических, астрономических, геологических и др. приложениях).

1.3. Точно совпадает с диапазоном диапазона .NET DateTimeтипа (хотя оба конвертируются туда и обратно без специального кодирования, если значения находятся в пределах диапазона и точности целевого типа, за исключением Con # 2.1 ниже, иначе произойдет ошибка / округление).

1.4. Более высокая точность (100 наносекунд, то есть 0,000,000,1 секунды против 3,33 миллисекунды, то есть 0,003,33 секунды) (хотя дополнительная точность, скорее всего, не будет использоваться, за исключением, например, в инженерных / научных приложениях).

1,5. При настройке на аналогичную (как в 1 миллисекунде не «ту же» (как в 3.33 миллисекундах), как утверждал Иман Абиди) точность, поскольку она DateTimeиспользует меньше места (7 против 8 байт), но тогда, конечно, вы потеряете прецизионная выгода, которая, вероятно, является одной из двух (другая - диапазон), которую чаще всего рекламируют, хотя, скорее всего, это и ненужные выгоды).

2. МИНУСЫ:

2.1. При передаче параметра в .NET SqlCommandвы должны указать, можете System.Data.SqlDbType.DateTime2ли вы передавать значение за пределы DateTimeдиапазона и / или точности SQL Server , поскольку по умолчанию оно равноSystem.Data.SqlDbType.DateTime .

2.2. Невозможно неявно / легко преобразовать в числовое значение с плавающей запятой (число дней с минимальной даты и времени), чтобы выполнить следующие действия в / в выражениях SQL Server с использованием числовых значений и операторов:

2.2.1. добавить или вычесть # дней или неполных дней. Примечание. Использование DateAddфункции в качестве обходного пути не является тривиальным, когда нужно учитывать несколько, если не все части даты-времени.

2.2.2. возьмите разницу между двумя датами для расчета «возраста». Примечание. DateDiffВместо этого нельзя просто использовать функцию SQL Server , поскольку она не вычисляет, ageкак большинство людей ожидают в этом случае, если две даты-времени пересекают границу даты и времени календаря / часов, указанную в единицах измерения, даже если для крошечной дроби для этой единицы, она вернет разницу как 1 от этой единицы против 0. Например, DateDiffин Day-ы двух дат-раз с разницей всего в 1 миллисекунду вернут 1 против 0 (дней), если эти даты-времена в разные календарные дни (т.е. «1999-12-31 23: 59: 59.9999999» и «2000-01-01 00: 00: 00.0000000»). Те же самые значения даты-времени с разницей в 1 миллисекунду, если они не пересекают календарный день, возвращают значение «DateDiff» вDay '0 (дней).

2.2.3. возьмите Avgдату-время (в агрегированном запросе), просто преобразовав сначала «Float», а затем снова обратно в DateTime.

ПРИМЕЧАНИЕ. Для преобразования DateTime2в числовое значение необходимо выполнить что-то вроде следующей формулы, которая по-прежнему предполагает, что ваши значения не меньше, чем в 1970 году (что означает, что вы теряете весь дополнительный диапазон плюс еще 217 лет. Примечание. не сможет просто изменить формулу, чтобы учесть дополнительный диапазон, потому что вы можете столкнуться с проблемами переполнения чисел.

25567 + (DATEDIFF(SECOND, {d '1970-01-01'}, @Time) + DATEPART(nanosecond, @Time) / 1.0E + 9) / 86400.0- Источник: « https://siderite.dev/blog/how-to-translate-t-sql-datetime2-to.html »

Конечно, вы можете также Castв DateTimeпервый (и при необходимости снова к DateTime2), но вы потеряете точность и диапазон (все предшествующие года 1753) выгоды от DateTime2VS. DateTimeкоторые Prolly 2 самых больших и также одновременно Prolly 2 наименее вероятно, что необходимо, и напрашивается вопрос, зачем его использовать, когда вы теряете неявные / простые преобразования в числовые с плавающей запятой (# дней) для сложения / вычитания / "возраста" (против DateDiff) /Avg выгоды calcs, которая является большой по моему опыту.

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

DateTime2 наносит ущерб, если вы - разработчик Access, пытающийся написать Now () для рассматриваемого поля. Просто выполнил миграцию Access -> SQL 2008 R2 и поместил все поля даты и времени в DateTime2. Добавление записи с Now () в качестве значения, полученного в результате взрыва. Это было хорошо 01.01.2012 14:53:04, но не 10.01.2012 14:53:04.

Однажды персонаж сделал разницу. Надеюсь, это кому-нибудь поможет.

Вот пример, который покажет вам различия в размере хранилища (в байтах) и точности между smalldatetime, datetime, datetime2 (0) и datetime2 (7):

DECLARE @temp TABLE (
    sdt smalldatetime,
    dt datetime,
    dt20 datetime2(0),
    dt27 datetime2(7)
)

INSERT @temp
SELECT getdate(),getdate(),getdate(),getdate()

SELECT sdt,DATALENGTH(sdt) as sdt_bytes,
    dt,DATALENGTH(dt) as dt_bytes,
    dt20,DATALENGTH(dt20) as dt20_bytes,
    dt27, DATALENGTH(dt27) as dt27_bytes FROM @temp

который возвращается

sdt                  sdt_bytes  dt                       dt_bytes  dt20                 dt20_bytes  dt27                         dt27_bytes
2015-09-11 11:26:00  4          2015-09-11 11:25:42.417  8         2015-09-11 11:25:42  6           2015-09-11 11:25:42.4170000  8

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

хотя с datetime2 повышена точность , некоторые клиенты не поддерживают date , time или datetime2 и вынуждают вас преобразовывать в строковый литерал. В частности, Microsoft упоминает проблемы ODBC, OLE DB, JDBC и SqlClient «нижнего уровня» с этими типами данных и имеет диаграмму, показывающую, как каждый может сопоставить тип.

Если значение совместимости выше точности, используйте datetime

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

Datetime2 быстрее при использовании в критериях фильтра.

TLDR:

В SQL 2016 у меня была таблица с сотнями тысяч строк и столбцом datetime ENTRY_TIME, потому что требовалось хранить точное время до секунд. При выполнении сложного запроса со многими объединениями и подзапросом, когда я использовал выражение where как:

WHERE ENTRY_TIME >= '2017-01-01 00:00:00' AND ENTRY_TIME < '2018-01-01 00:00:00'

Первоначально запрос выполнялся нормально, когда были сотни строк, но когда количество строк увеличилось, запрос начал выдавать эту ошибку:

Execution Timeout Expired. The timeout period elapsed prior
to completion of the operation or the server is not responding.

Я удалил предложение where, и неожиданно запрос был выполнен за 1 секунду, хотя теперь были получены ВСЕ строки для всех дат. Я запускаю внутренний запрос с предложением where, и это заняло 85 секунд, а без предложения where - 0,01 секунды.

Я сталкивался здесь со многими потоками для этой проблемы как производительность фильтрации по времени и дате

Я немного оптимизировал запрос. Но реальная скорость, которую я получил, заключалась в изменении столбца datetime на datetime2.

Теперь тот же запрос, который был ранее заблокирован, занимает менее секунды.

ура

Интерпретация строк даты в datetimeи datetime2может отличаться, если используются DATEFORMATнастройки за пределами США . Например

set dateformat dmy
declare @d datetime, @d2 datetime2
select @d = '2013-06-05', @d2 = '2013-06-05'
select @d, @d2

Это возвращает 2013-05-06(т.е. 6 мая) для datetime, и 2013-06-05(т.е. 5 июня) для datetime2. Однако с dateformatset to mdy, оба @dи @d2возвращаются 2013-06-05.

Такое datetimeповедение противоречит документации MSDN, в SET DATEFORMATкоторой говорится: Некоторые форматы символьных строк, например ISO 8601, интерпретируются независимо от параметра DATEFORMAT . Очевидно, не правда!

Пока меня это не укусило, я всегда думал, что yyyy-mm-ddдаты будут обрабатываться правильно, независимо от настроек языка / локали.

Согласно этой статье , если вы хотите иметь одинаковую точность DateTime с использованием DateTime2, вы просто должны использовать DateTime2 (3). Это должно дать вам ту же точность, занимать на один байт меньше и обеспечить расширенный диапазон.

Я просто наткнулся на еще одно преимущество DATETIME2: он позволяет избежать ошибки в adodbapiмодуле Python , которая взрывается, если datetimeпередается стандартное библиотечное значение, которое имеет ненулевые микросекунды для DATETIMEстолбца, но работает нормально, если столбец определен как DATETIME2.

Select ValidUntil + 1
from Documents

Приведенный выше SQL не будет работать с полем DateTime2. Возвращается сообщение об ошибке «Тип операнда clash: datetime2 несовместим с int»

Добавление 1 для получения следующего дня - это то, что разработчики делали с датами в течение многих лет. Теперь у Microsoft есть супер новое поле datetime2, которое не может справиться с этой простой функциональностью.

«Давайте использовать этот новый тип, который хуже старого», я так не думаю!

Я думаю, что DATETIME2это лучший способ хранить date, потому что он имеет большую эффективность, чем DATETIME. В SQL Server 2008вы можете использовать DATETIME2, он хранит дату и время, занимает 6-8 bytesдля хранения и имеет точность 100 nanoseconds. Так что каждый, кто нуждается в большей точности времени, захочет DATETIME2.