Розмір 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'). Це додасть складності коду.