Ukuran dateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3) menggunakan jumlah penyimpanan yang sama. (6 Bytes)
Apakah saya benar mengatakan bahwa saya mungkin akan pergi dengan dateTime2 (3) dan mendapatkan manfaat dari ketepatan tanpa biaya ukuran tambahan.
Tidak, Anda salah menafsirkan dokumentasi. Perhatikan dokumen menyatakan ukuran penyimpanan 6 byte untuk precision kurang dari 3 (penekanan milik saya). Jadi ketelitian sama dengan 3 akan membutuhkan 7 byte.
Jika Anda tidak peduli tentang milidetik, datetime2(0) akan menjadi tipe data yang tepat dan presisi. Praktik terbaik adalah menentukan jenis data yang tepat dan presisi berdasarkan data yang disimpan karena ini akan secara inheren memberikan penyimpanan dan efisiensi yang optimal. Yang sedang berkata, saya tidak akan mengharapkan dampak kinerja yang signifikan berdasarkan presisi datetime2 yang ditentukan selama ukuran penyimpanannya sama tetapi saya belum secara khusus menguji sendiri.
Persyaratan aplikasi akan menentukan apa yang harus disimpan dalam database ketika ketelitian yang lebih besar tersedia di sumbernya. Misalnya, untuk waktu entri pesanan yang bersumber SYSDATETIME(), pengguna mungkin tidak ingin presisi 100 nanodetik. Sekali lagi, pilih tipe data dan presisi untuk pengembangan baru sesuai dengan persyaratan dan Anda umumnya akan mendapatkan kinerja yang optimal tanpa pemikiran tambahan:
Meskipun datetime2 paling tepat untuk pengembangan baru seperti yang tercantum di atas, seseorang kadang-kadang mungkin perlu menggunakan datetime (ketepatan tetap 3 dengan 1/300 fraksi detik akurasi) alih-alih untuk kompatibilitas dengan aplikasi datetime warisan, sehingga menghindari konversi implisit dan perilaku perbandingan yang tidak terduga, tetapi pada biaya akurasi pecahan kedua dan peningkatan penyimpanan.
Pertimbangkan bahwa menyimpan presisi yang lebih besar dari yang dibutuhkan juga mungkin memiliki biaya pengembangan. Jika seseorang menyimpan komponen waktu dengan detik fraksional ketika hanya presisi seluruh detik diperlukan, kueri masih perlu mempertimbangkan detik fraksional untuk mengembalikan hasil yang benar. Misalnya, dengan aplikasi tempat pengguna memilih rentang waktu melalui UI yang hanya memungkinkan seluruh detik, kode aplikasi harus memperhitungkan detik fraksional dalam nilai rentang waktu akhir dan menyesuaikan nilai yang disediakan pengguna sesuai (misalnya WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'atau WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'). Ini akan menambah kompleksitas kode.