datetime2 (0) vs datetime2 (2)

Datetime2 (Transact-SQL) belgelerine göre :

Depolama boyutu
6 3'ten daha Precisions için bayt
precisions 3 ve 4 7 bayt
Diğer tüm presizyonları 8 bayt gerektirir.

Büyüklüğü datetime2(0), datetime2(1), datetime2(2)depolama, aynı miktarda (6 bayt) kullanın.

datetime2(2)Herhangi bir ek boyut maliyeti olmadan da gidip hassasiyetten faydalanabileceğimi söyleyebilir miyim ?

Lütfen aklınızda bulundurun:

• Bu sütun, bileşik kümelenmiş bir dizin oluşturmak için PK ile dizinlenir (tablo bölümleme için kullanılır)
• Milisaniye umrumda değil

Misiniz datetime2(0)bir yerde yan tümcesinde kullanıldığında daha cpu verimli olabilir veya bir dizin aracılığıyla ararken?

Bu büyük bir tablo, bu nedenle en küçük optimizasyon büyük bir fark yaratacak.

DateTime2 (0), dateTime2 (1), dateTime2 (2), dateTime2 (3) boyutu aynı miktarda depolama alanı kullanır. (6 Bayt)

Ben de dateTime2 (3) ile gidip herhangi bir ek boyut maliyeti olmadan hassasiyet yarar elde söyleyebilirim doğru olur.

Hayır, belgeleri yanlış yorumladınız. Doktor durumları Not hassasiyetleri için depolama boyutu 6 bayt az 3 (vurgu madeni). Yani 3'e eşit bir hassasiyet 7 bayt gerektirir.

Milisaniye ile ilgilenmiyorsanız datetime2(0), doğru veri türü ve hassasiyeti olacaktır. En iyi uygulama, doğal olarak en uygun depolama ve verimliliği sağlayacağından depolanan verilere göre uygun veri türünü ve hassasiyetini belirtmektir. Bununla birlikte, depolama boyutu aynı olduğu sürece, belirtilen datetime2 hassasiyetine dayanan önemli bir performans etkisi beklemiyordum, ancak kendimi özel olarak test etmedim.

Uygulama gereksinimleri, kaynakta daha büyük bir hassasiyet olduğunda veritabanında nelerin depolanması gerektiğini belirler. Örneğin, kaynaklı sipariş siparişi için SYSDATETIME()kullanıcılar 100 nanosaniye hassasiyet istemeyebilir. Yine, gereksinimlere göre yeni geliştirme için veri türünü ve hassasiyetini seçin ve genellikle ek düşünce olmadan optimum performans elde edersiniz:

• randevu - zamana ihtiyacın yok
• smalldatetime - saniyeler gerekmez
• datetime2 (0) - kesirli saniyeye ihtiyacınız yok
• datetime2 (1-7) - belirtilen hassasiyetin kesirli saniyelerine ihtiyacınız var
• datetimeoffset (0-7) - saat dilimi farkındalığı olan tarih ve saate ihtiyacınız var
• zaman (0-7) - belirtilen hassasiyetin kesirli saniyeleriyle yalnızca zamana (tarih yok) ihtiyacınız var

Datetime2, yukarıda listelenen yeni geliştirme için en uygun olsa da, bazen eski datetime uygulamalarıyla uyumluluk için yerine datetime (1/300 kesirli saniye doğruluğu ile sabit hassasiyet 3) kullanılması gerekebilir ; kesirli ikinci doğruluk ve artan depolama masrafı.

Gerekenden daha büyük bir hassasiyetin depolanmasının bir geliştirme maliyetine sahip olabileceğini düşünün. Bir zaman bileşenini yalnızca tam bir ikinci hassasiyet gerekli olduğunda kesirli saniye ile saklarsa, sorguların yine de doğru sonuçları döndürmek için kesirli saniyeleri dikkate alması gerekir. Örneğin, kullanıcının yalnızca tam saniye için izin veren bir kullanıcı arayüzü üzerinden bir zaman aralığı seçtiği bir uygulamada, uygulama kodunun bitiş zaman aralığı değerindeki kesirli saniyeleri hesaba katması ve kullanıcı tarafından sağlanan değeri buna göre ayarlaması gerekir (ör. WHERE OrderEntryTime BETWEEN '2017-01-11T08:00:00.00.00' AND '2017-01-11T08:59:59.99'veya WHERE OrderEntryTime >= '2017-01-11T08:00:00.00' AND OrderEntryTime < '2017-01-11T09:00:00.00'). Bu kod karmaşıklığı ekleyecektir.