Размеры dateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3) используют одинаковый объем памяти. (6 байт)
Буду ли я прав, говоря, что я мог бы также пойти с dateTime2 (3) и получить преимущество точности без каких-либо дополнительных затрат на размер.
Нет, вы неверно истолковали документацию. Обратите внимание, что объем хранения документов в документообороте составляет 6 байт для точности менее 3 (выделено). Таким образом, точность, равная 3, потребует 7 байтов.
Если вас не волнуют миллисекунды, datetime2(0)будет правильный тип данных и точность. Рекомендуется указывать правильный тип и точность данных на основе хранимых данных, поскольку это по сути обеспечивает оптимальное хранение и эффективность. При этом я не ожидал бы значительного влияния на производительность на основе указанной точности datetime2, если размер хранилища такой же, но я специально не проверял это сам.
Требования к приложениям определяют, что должно храниться в базе данных, когда в источнике доступна более высокая точность. Например, для времени ввода заказа, полученного от SYSDATETIME(), пользователи могут не захотеть точность до 100 наносекунд. Опять же, выберите тип данных и точность для новой разработки в соответствии с требованиями, и вы, как правило, получите оптимальную производительность без дополнительных размышлений:
Хотя 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'). Это добавит сложности кода.