DateTime2 vs DateTime di SQL Server

Yang mana:

• datetime
• datetime2

adalah yang cara yang direkomendasikan untuk tanggal menyimpan dan waktu di SQL Server 2008+?

Saya menyadari perbedaan dalam presisi (dan kemungkinan ruang penyimpanan), tetapi mengabaikannya untuk saat ini, apakah ada dokumen praktik terbaik tentang kapan harus menggunakan apa, atau mungkin sebaiknya kita hanya menggunakan datetime2saja?

Dokumentasi MSDN untuk datetime merekomendasikan penggunaan datetime2 . Berikut rekomendasi mereka:

Gunakan time, date, datetime2dan datetimeoffsettipe data untuk pekerjaan baru. Jenis-jenis ini sejajar dengan SQL Standard. Mereka lebih portabel. time, datetime2dan datetimeoffset memberikan lebih banyak presisi detik. datetimeoffsetmemberikan dukungan zona waktu untuk aplikasi yang digunakan secara global.

datetime2 memiliki rentang tanggal yang lebih besar, presisi fraksional default yang lebih besar, dan presisi opsional yang ditentukan pengguna. Juga tergantung pada presisi yang ditentukan pengguna mungkin menggunakan lebih sedikit penyimpanan.

DATETIME2memiliki rentang tanggal "0001/01/01" hingga " DATETIME9999/12/31 " sedangkan jenisnya hanya mendukung tahun 1753-9999.

Juga, jika perlu, DATETIME2bisa lebih tepat dalam hal waktu; DATETIME terbatas pada 3 1/3 milidetik, sementara DATETIME2dapat akurat hingga 100ns.

Kedua jenis peta untuk System.DateTimedi. NET - tidak ada perbedaan di sana.

Jika Anda punya pilihan, saya akan merekomendasikan menggunakan DATETIME2sedapat mungkin. Saya tidak melihat manfaat menggunakan DATETIME(kecuali untuk kompatibilitas mundur) - Anda akan memiliki lebih sedikit masalah (dengan tanggal di luar jangkauan dan kerumitan seperti itu).

Plus: jika Anda hanya perlu tanggal (tanpa waktu), gunakan DATE - itu sama baiknya DATETIME2dan menghemat ruang Anda juga! :-) Hal yang sama berlaku hanya untuk waktu - gunakan TIME. Untuk itulah jenis-jenis ini ada!

datetime2 menang di sebagian besar aspek kecuali (Kompatibilitas aplikasi lama)

1. rentang nilai yang lebih besar
2. Akurasi yang lebih baik
3. ruang penyimpanan yang lebih kecil (jika presisi yang ditentukan pengguna opsional ditentukan)

harap perhatikan poin-poin berikut

• Sintaksis
  • datetime2 [(presisi pecahan detik => Lihat Di Bawah Ukuran Penyimpanan)]
• Presisi, skala
  • 0 hingga 7 digit, dengan akurasi 100ns.
  • Ketepatan standar adalah 7 digit.
• Ukuran penyimpanan
  • 6 byte untuk presisi kurang dari 3;
  • 7 byte untuk presisi 3 dan 4.
  • Semua presisi lainnya membutuhkan 8 byte .
• DateTime2 (3) memiliki jumlah digit yang sama dengan DateTime tetapi menggunakan 7 byte penyimpanan, bukan 8 byte ( SQLHINTS- DateTime Vs DateTime2 )
• Temukan lebih lanjut tentang datetime2 (Artikel Transact-SQL MSDN)

sumber gambar: MCTS Self-Paced Training Kit (Ujian 70-432): Microsoft® SQL Server® 2008 - Implementasi dan Pemeliharaan Bab 3: Tabel -> Pelajaran 1: Membuat Tabel -> halaman 66

Saya setuju dengan @marc_s dan @Adam_Poward - DateTime2 adalah metode yang disukai untuk bergerak maju. Ini memiliki rentang tanggal yang lebih luas, presisi lebih tinggi, dan menggunakan penyimpanan yang sama atau kurang (tergantung pada presisi).

Satu hal diskusi terjawab, namun ...
@Marc_s menyatakan: Both types map to System.DateTime in .NET - no difference there. Ini benar, namun, kebalikannya tidak benar ... dan itu penting ketika melakukan pencarian rentang tanggal (mis. "Temukan saya semua catatan yang diubah pada 5/5/2010").

Versi .NET Datetimememiliki kisaran dan ketepatan yang mirip dengan DateTime2. Ketika pemetaan .net sebuah Datetimeturun ke SQL tua DateTimemerupakan pembulatan implisit terjadi . SQL lama DateTimeakurat hingga 3 milidetik. Ini berarti 11:59:59.997sedekat yang Anda bisa sampai pada akhir hari. Apa pun yang lebih tinggi dibulatkan ke hari berikutnya.

Coba ini :

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'

Menghindari pembulatan tersirat ini adalah alasan penting untuk pindah ke DateTime2. Pembulatan tanggal secara implisit jelas menyebabkan kebingungan:

• Perilaku datetime yang aneh di SQL Server
• http://bytes.com/topic/sql-server/answers/578416-weird-millisecond-part-datetime-data-sql-server-2000-a
• SQL Server 2008 dan milidetik
• 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

Hampir semua Jawaban dan Komentar berat di Pro dan ringan di Kontra. Berikut adalah ringkasan dari semua Pro dan Kontra sejauh ini ditambah beberapa Kontra penting (dalam # 2 di bawah) Saya hanya pernah melihat disebutkan sekali atau tidak sama sekali.

1. PROS:

1.1. Lebih banyak ISO yang sesuai (ISO 8601) (walaupun saya tidak tahu bagaimana hal ini bisa dilakukan dalam praktiknya).

1.2. Lebih banyak rentang (1/1/0001 hingga 12/31/9999 vs. 1/1 / 1753-12 / 31/9999) (meskipun rentang ekstra, semua sebelum tahun 1753, kemungkinan tidak akan digunakan kecuali untuk mantan, dalam aplikasi historis, astronomi, geologi, dll.).

1.3. Persis cocok dengan rentang rentang .NET's DateTimeType (meskipun keduanya mengkonversi bolak-balik tanpa pengkodean khusus jika nilai-nilai berada dalam kisaran dan ketepatan jenis target kecuali untuk Con # 2.1 di bawah yang lain kesalahan / pembulatan akan terjadi).

1.4. Lebih presisi (100 nanosecond alias 0,000,000,1 dtk vs 3,33 milisecond alias 0,003,33 dtk) (walaupun presisi ekstra kemungkinan tidak akan digunakan kecuali untuk mantan, dalam rekayasa / aplikasi ilmiah).

1.5. Ketika dikonfigurasi untuk serupa (seperti dalam 1 milidetik tidak "sama" (seperti dalam 3,33 milidetik) seperti yang diklaim Iman Abidi) presisi DateTime, menggunakan lebih sedikit ruang (7 vs 8 byte), tetapi tentu saja, Anda akan kehilangan manfaat presisi yang kemungkinan merupakan salah satu dari dua (kisaran lainnya) yang paling dipuji meskipun kemungkinan manfaat yang tidak dibutuhkan).

2. CONS:

2.1. Ketika melewati Parameter ke. NET SqlCommand, Anda harus menentukan System.Data.SqlDbType.DateTime2apakah Anda mungkin melewati nilai di luar DateTimerentang dan / atau presisi SQL Server , karena itu default untuk System.Data.SqlDbType.DateTime.

2.2. Tidak dapat secara implisit / mudah dikonversi ke nilai numerik floating-point (# hari sejak min date-time) untuk melakukan hal berikut ke / dengan itu dalam ekspresi SQL Server menggunakan nilai numerik dan operator:

2.2.1. tambahkan atau kurangi # hari atau sebagian hari. Catatan: Menggunakan DateAddFungsi sebagai solusi bukanlah hal yang sepele ketika Anda perlu mempertimbangkan banyak jika tidak semua bagian dari tanggal-waktu.

2.2.2. ambil perbedaan antara dua kali tanggal untuk keperluan perhitungan "usia". Catatan: Anda tidak bisa hanya menggunakan DateDiffFungsi SQL Server sebagai gantinya, karena itu tidak menghitung ageseperti yang diharapkan kebanyakan orang bahwa jika dua tanggal-waktu terjadi untuk melintasi batas kalender / jam tanggal-waktu dari unit yang ditentukan jika bahkan untuk sebagian kecil dari unit itu, ia akan mengembalikan selisih 1 dari unit itu vs 0. Misalnya, DateDiffdalam Daydua kali tanggal hanya terpisah 1 milidetik akan mengembalikan 1 vs 0 (hari) jika waktu-waktu tersebut adalah pada hari kalender yang berbeda (yaitu "1999-12-31 23: 59: 59.9999999" dan "2000-01-01 00: 00: 00.0000000"). Perbedaan waktu yang sama 1 milidetik jika dipindahkan sehingga tidak melewati hari kalender, akan mengembalikan "DateDiff" dalam Day0 (hari).

2.2.3. ambil Avgtanggal-waktu (dalam Kueri Agregat) dengan hanya mengonversi ke "Float" terlebih dahulu dan kemudian kembali lagi ke DateTime.

CATATAN: Untuk mengonversi DateTime2menjadi angka, Anda harus melakukan sesuatu seperti rumus berikut yang masih mengasumsikan nilai Anda tidak kurang dari tahun 1970 (yang berarti Anda kehilangan semua rentang tambahan ditambah 217 tahun lagi. Catatan: Anda dapat tidak dapat hanya menyesuaikan rumus untuk memungkinkan rentang tambahan karena Anda dapat mengalami masalah luapan numerik.

25567 + (DATEDIFF(SECOND, {d '1970-01-01'}, @Time) + DATEPART(nanosecond, @Time) / 1.0E + 9) / 86400.0- Sumber: " https://siderite.dev/blog/how-to-translate-t-sql-datetime2-to.html "

Tentu saja, Anda bisa juga Castuntuk yang DateTimepertama (dan jika perlu kembali lagi ke DateTime2), tetapi Anda akan kehilangan ketepatan dan jangkauan (semua sebelum tahun 1753) manfaat DateTime2vs DateTimeyang merupakan 2 terbesar dan juga pada saat yang sama prolly 2 yang paling tidak mungkin diperlukan yang menimbulkan pertanyaan mengapa menggunakannya ketika Anda kehilangan konversi implisit / mudah ke angka floating-point (# hari) untuk tambahan / pengurangan / "usia" (vs DateDiff) / Avgmanfaat calc yang merupakan hal besar dalam pengalaman saya.

Btw, Avgtanggal-waktu adalah (atau setidaknya seharusnya ) kasus penggunaan yang penting. a) Selain digunakan dalam mendapatkan durasi rata-rata ketika tanggal-waktu (karena tanggal-waktu basis umum) digunakan untuk mewakili durasi (praktik umum), b) juga berguna untuk mendapatkan statistik tipe dasbor tentang apa yang rata-rata tanggal- waktu dalam kolom tanggal-waktu dari rentang / grup Baris. c) Standar (atau paling tidak harus standar) Permintaan ad-hoc untuk memantau / memecahkan masalah nilai-nilai dalam suatu Kolom yang mungkin tidak berlaku lagi / lebih lama dan / atau mungkin perlu dihentikan adalah mendaftar untuk setiap nilai hitungan kejadian dan (jika tersedia) perangko Min, Avgdan Maxtanggal-waktu yang terkait dengan nilai itu.

DateTime2 mendatangkan malapetaka jika Anda adalah seorang pengembang Access yang mencoba menulis Now () ke bidang yang dimaksud. Baru saja melakukan Access -> SQL 2008 R2 migrasi dan itu menempatkan semua bidang datetime sebagai DateTime2. Menambahkan catatan dengan Now () saat nilainya dibom. Tidak apa-apa pada 1/1/2012 14:53:04 PM, tetapi tidak pada 1/10/2012 14:53:04 PM.

Setelah karakter membuat perbedaan. Semoga ini bisa membantu seseorang.

Berikut ini adalah contoh yang akan menunjukkan kepada Anda perbedaan dalam ukuran penyimpanan (byte) dan presisi antara waktu-kecil, waktu-waktu, datetime2 (0), dan 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

yang kembali

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

Jadi jika saya ingin menyimpan informasi hingga detik - tetapi tidak ke milidetik - saya dapat menyimpan masing-masing 2 byte jika saya menggunakan datetime2 (0) alih-alih datetime atau datetime2 (7).

sementara ada peningkatan presisi dengan datetime2 , beberapa klien tidak mendukung tanggal , waktu , atau datetime2 dan memaksa Anda untuk mengonversi ke string literal. Secara khusus Microsoft menyebutkan "down level" ODBC, OLE DB, JDBC, dan SqlClient masalah dengan tipe data ini dan memiliki bagan yang menunjukkan bagaimana masing-masing dapat memetakan jenis.

Jika kompatibilitas nilai lebih dari presisi, gunakan datetime

Pertanyaan Lama ... Tapi saya ingin menambahkan sesuatu yang belum dinyatakan oleh siapa pun di sini ... (Catatan: Ini adalah pengamatan saya sendiri, jadi jangan minta referensi apa pun)

Datetime2 lebih cepat bila digunakan dalam kriteria filter.

TLDR:

Di SQL 2016 saya punya tabel dengan ratusan ribu baris dan kolom datetime ENTRY_TIME karena itu diperlukan untuk menyimpan waktu yang tepat hingga detik. Saat menjalankan kueri yang kompleks dengan banyak gabungan dan sub kueri, saat saya menggunakan klausa mana sebagai:

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

Awalnya permintaan baik-baik saja ketika ada ratusan baris, tetapi ketika jumlah baris meningkat, permintaan mulai memberikan kesalahan ini:

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

Saya menghapus klausa tempat, dan tanpa terduga, kueri dijalankan dalam 1 detik, meskipun sekarang SEMUA baris untuk semua tanggal diambil. Saya menjalankan kueri batin dengan di mana klausa, dan butuh 85 detik, dan tanpa klausa mana butuh 0,01 detik.

Saya menemukan banyak utas di sini untuk masalah ini sebagai kinerja penyaringan datetime

Saya sedikit mengoptimalkan permintaan. Tapi kecepatan sebenarnya yang saya dapatkan adalah dengan mengubah kolom datetime ke datetime2.

Sekarang permintaan yang sama yang waktunya habis sebelumnya membutuhkan waktu kurang dari satu detik.

Bersulang

Interpretasi string tanggal menjadi datetimedan datetime2bisa berbeda juga, saat menggunakan DATEFORMATpengaturan non-AS . Misalnya

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

Ini mengembalikan 2013-05-06(yaitu 6 Mei) untuk datetime, dan 2013-06-05(yaitu 5 Juni) untuk datetime2. Namun, dengan dateformatdisetel ke mdy, keduanya @ddan @d2kembali2013-06-05 .

The datetimeperilaku tampaknya bertentangan dengan dokumentasi MSDN dari SET DATEFORMATyang menyatakan: Beberapa format string karakter, misalnya ISO 8601, ditafsirkan secara independen dari pengaturan DateFormat . Jelas tidak benar!

Sampai saya digigit oleh ini, saya selalu berpikir bahwa yyyy-mm-ddtanggal hanya akan ditangani dengan benar, terlepas dari pengaturan bahasa / lokal.

Menurut artikel ini , jika Anda ingin memiliki ketepatan DateTime yang sama menggunakan DateTime2 Anda cukup menggunakan DateTime2 (3). Ini akan memberi Anda presisi yang sama, mengambil satu byte lebih sedikit, dan memberikan rentang yang diperluas.

Saya hanya menemukan satu keuntungan lagi untuk DATETIME2: ia menghindari bug dalam adodbapimodul Python , yang meledak jika datetimenilai pustaka standar dilewatkan yang memiliki mikrodetik bukan nol untuk DATETIMEkolom tetapi berfungsi dengan baik jika kolom didefinisikan sebagai DATETIME2.

Select ValidUntil + 1
from Documents

SQL di atas tidak akan berfungsi dengan bidang DateTime2. Ini kembali dan kesalahan "Operan tipe clash: datetime2 tidak kompatibel dengan int"

Menambahkan 1 untuk mendapatkan hari berikutnya adalah sesuatu yang telah dilakukan pengembang dengan tanggal selama bertahun-tahun. Sekarang Microsoft memiliki bidang datetime2 super baru yang tidak dapat menangani fungsi sederhana ini.

"Mari kita gunakan tipe baru ini yang lebih buruk daripada yang lama", kurasa tidak!

Saya pikir DATETIME2ini adalah cara yang lebih baik untuk menyimpan date, karena memiliki efisiensi lebih dari DATETIME. Dalam SQL Server 2008Anda dapat menggunakan DATETIME2, menyimpan tanggal dan waktu, dibutuhkan 6-8 bytesuntuk menyimpan dan memiliki presisi 100 nanoseconds. Jadi siapa pun yang membutuhkan ketepatan waktu yang lebih besar akan menginginkannya DATETIME2.