datetime2 (0) vs datetime2 (2)

Menurut dokumentasi datetime2 (Transact-SQL) :

Ukuran penyimpanan
6 byte untuk precision kurang dari 3.
7 byte untuk precision 3 dan 4.
Semua precision lainnya memerlukan 8 byte.

Ukuran datetime2(0), datetime2(1), datetime2(2)menggunakan jumlah yang sama penyimpanan (6 byte).

Apakah saya benar mengatakan bahwa saya mungkin akan ikut serta datetime2(2)dan mendapatkan manfaat dari ketepatan tanpa biaya ukuran tambahan?

Tolong dicatat:

• Kolom ini diindeks dengan PK untuk membentuk indeks gabungan majemuk (digunakan untuk partisi tabel)
• Saya tidak peduli dengan milidetik

Akan datetime2(0)lebih efisien CPU ketika digunakan di mana klausa, atau ketika mencari melalui indeks?

Ini adalah tabel besar, jadi pengoptimalan terkecil akan membuat perbedaan besar.

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:

• tanggal - Anda tidak perlu waktu
• smalldatetime - Anda tidak perlu detik
• datetime2 (0) - Anda tidak perlu pecahan detik
• datetime2 (1-7) - Anda perlu beberapa detik dari ketelitian yang ditentukan
• datetimeoffset (0-7) - Anda perlu tanggal dan waktu dengan kesadaran zona waktu
• waktu (0-7) - Anda hanya membutuhkan waktu (tanpa tanggal) dengan detik pecahan dari ketelitian yang ditentukan

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.