SQL Server'da DateTime2 ve DateTime

Hangisi:

• datetime
• datetime2

olan SQL Server 2008+ mağaza tarih ve saatine önerilen yoludur?

Hassasiyetteki farklılıkların (ve muhtemelen depolama alanlarının) farkındayım, ancak şimdilik bunları görmezden gelmek, neyi ne zaman kullanacağımızla ilgili en iyi uygulama belgesi datetime2mi yoksa sadece sadece kullanmalıyız ?

İçin MSDN belgelerine tarih saat kullanılmasını önerir datetime2 . İşte önerileri:

Kullanın time, date, datetime2ve datetimeoffsetyeni çalışmalar için veri türlerini. Bu türler SQL Standardı ile uyumludur. Daha portatiftirler. time, datetime2Ve datetimeoffset saniye daha hassas sağlar. datetimeoffsetglobal olarak dağıtılan uygulamalar için saat dilimi desteği sağlar.

datetime2, daha geniş bir tarih aralığına, daha büyük bir varsayılan kesirli kesime ve isteğe bağlı kullanıcı tanımlı bir kesime sahiptir. Ayrıca kullanıcı tarafından belirlenen hassasiyete bağlı olarak daha az depolama alanı kullanabilir.

DATETIME2" DATETIME0001/01/01 " ile " 9999/12/31 " tarih aralığına sahipken, tür yalnızca 1753-9999 yılını destekler.

Ayrıca, gerekirse DATETIME2, zaman açısından daha kesin olabilir; DATETIME 3 1/3 milisaniye ile sınırlıdır, DATETIME2100ns'e kadar doğru olabilir.

Her iki tür System.DateTimede .NET'te eşleşir - orada fark yoktur.

Seçiminiz varsa, DATETIME2mümkün olduğunda kullanmanızı tavsiye ederim . Kullanarak herhangi bir fayda görmüyorum DATETIME(geriye dönük uyumluluk hariç) - daha az sorun yaşayacaksınız (tarihler aralık dışında ve güçlükle).

Artı: sadece tarihe ihtiyacınız varsa (saat bölümü olmadan), DATE kullanın - tıpkı sizin kadar iyi DATETIME2ve yerden tasarruf sağlar! :-) Aynı şey sadece zaman için geçerlidir - kullanın TIME. Bu tipler bunun için var!

datetime2 (eski uygulamalar Uyumluluk) hariç birçok açıdan kazanır

1. daha geniş değer aralığı
2. daha iyi Doğruluk
3. daha küçük depolama alanı (isteğe bağlı kullanıcı tanımlı hassasiyet belirtilirse)

lütfen aşağıdaki noktalara dikkat edin

• Sözdizimi
  • datetime2 [(kesirli saniye hassasiyeti => Depolama Boyutunun Altına Bak)]
• Hassas ölçek
  • 100ns hassasiyetle 0 ila 7 basamak.
  • Varsayılan hassasiyet 7 basamaktır.
• Depolama boyutu
  • 3'ten az hassasiyet için 6 bayt;
  • Hassasiyet 3 ve 4 için 7 bayt.
  • Diğer tüm hassasiyetler 8 bayt gerektirir .
• DateTime2 (3) , DateTime ile aynı sayıda basamağa sahiptir, ancak 8 bayt yerine 7 bayt depolama alanı kullanır ( SQLHINTS- DateTime Vs DateTime2 )
• Datetime2 hakkında daha fazla bilgi edinin (Transact-SQL MSDN makalesi)

görüntü kaynağı: MCTS Kendi Hızınızda Eğitim Seti (Sınav 70-432): Microsoft® SQL Server® 2008 - Uygulama ve Bakım Bölüm 3: Tablolar -> Ders 1: Tablo Oluşturma -> sayfa 66

@Marc_s ve @Adam_Poward ile aynı fikirdeyim - DateTime2, ilerlemek için tercih edilen yöntem. Daha geniş bir tarih aralığına, daha yüksek hassasiyete sahiptir ve eşit veya daha az depolama kullanır (hassasiyete bağlı olarak).

Bir şey tartışma cevapsız Ancak ...
@Marc_s devletler: Both types map to System.DateTime in .NET - no difference there. Ancak bu doğrudur, tersi doğru değildir ... ve tarih aralığı aramaları yaparken önemlidir (örn. "5/5/2010 tarihinde değiştirilmiş tüm kayıtları bul").

.NET sürümü Datetimebenzer aralığı ve hassasiyete sahiptir DateTime2. Bir .net haritalama zaman Datetimeeski SQL aşağı DateTimebir örtük yuvarlama oluşur . Eski SQL DateTime3 milisaniyeye kadar doğrudur. Bu 11:59:59.997, günün sonuna ulaşabileceğiniz kadar yakın olduğu anlamına gelir . Daha yüksek her şey ertesi güne yuvarlanır.

Bunu dene :

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'

Bu örtük yuvarlamadan kaçınmak DateTime2 öğesine geçmek için önemli bir nedendir. Tarihlerin örtülü olarak yuvarlanması açıkça karışıklığa neden olur:

• SQL Server'da garip datetime davranışı
• http://bytes.com/topic/sql-server/answers/578416-weird-millisecond-part-datetime-data-sql-server-2000-a
• SQL Server 2008 ve milisaniye
• 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

Hemen hemen tüm Cevaplar ve Yorumlar Artıları ağır ve Eksileri hafif. İşte şimdiye kadar tüm Artıları ve Eksileri bir özeti artı bazı önemli Eksileri (aşağıda # 2) Ben sadece bir kez söz ya da hiç bahsettiğini gördüm.

1. Artıları:

1.1. Daha fazla ISO uyumlu (ISO 8601) (bunun pratikte nasıl oynandığını bilmememe rağmen).

1.2. Daha fazla menzil (1/1/0001 ila 12/31/9999 / 1/1 / 1753-12 / 31/9999) (1753 yılından önceki tüm ekstra menzil, örneğin, hariç, muhtemelen kullanılmayacaktır, tarihsel, astronomik, jeolojik vb. uygulamalarda).

1.3. .NET DateTimeTürünün aralık aralığıyla tam olarak eşleşir (her ne kadar değerler hedef türün aralığı ve hassasiyeti dahilinde ise, başka hata / yuvarlama gerçekleşmeyecekse, özel bir kodlama olmadan hem ileri hem de geri dönüş yapmasına rağmen).

1.4. Daha fazla hassasiyet (100 nanosaniye aka 0.000.000,1 sn., 3.33 milisaniye aka 0.003,33 sn.) (Mühendislik / bilimsel uygulamalarda ekstra hassasiyet muhtemelen kullanılmayacak olsa da).

1.5. Iman Abidi'nin iddia ettiği gibi benzer (1 milisaniyede değil "aynı" (3.33 milisaniyede olduğu gibi) için yapılandırıldığında DateTime, daha az alan kullanır (7'ye 8 bayt), ancak elbette, büyük olasılıkla gereksiz faydalar da dahil olmak üzere en çok lanse edilen iki (diğeri aralık) olan hassas fayda.

2. EKSİLERİ:

2.1. Bir Parametreyi bir .NET'e geçirirken, varsayılan olarak SQL Server'ın aralığı ve / veya hassasiyeti dışında bir değer geçirip geçiremeyeceğinizi SqlCommandbelirtmeniz gerekir .System.Data.SqlDbType.DateTime2DateTimeSystem.Data.SqlDbType.DateTime

2.2. SQL Server ifadelerinde sayısal değerler ve işleçler kullanarak aşağıdakileri yapmak için dolaylı / kolayca kayan nokta sayısalına (dk tarih-saatinden beri geçen gün sayısı) dönüştürülemez:

2.2.1. gün veya kısmi gün ekleme veya çıkarma. Not: DateAddİşlev'i geçici bir çözüm olarak kullanmak , tarih saatinin tüm bölümleri olmasa da birden fazla düşünmeniz gerektiğinde önemsiz değildir.

2.2.2. “yaş” hesaplaması için iki tarih-saat arasındaki farkı alır. Not: Bunun DateDiffyerine SQL Server'ın İşlevini kullanamazsınız , çünkü ageçoğu insanın beklediği gibi hesaplanmaz, çünkü iki tarih-saati, küçük bir kesir için bile olsa belirtilen birimlerin bir takvim / saat tarih-saat sınırını geçerse bu birimin, bu Örneğin 0'a karşı o birimin 1 olarak farkını dönersiniz, DateDiffiçinde Day'sadece 1 milisaniye arayla bu tarih-kat ise 1 vs 0 (gün) dönecektir iki tarih-kez s farklı takvim günlerinde (ör. “1999-12-31 23: 59: 59.9999999” ve “2000-01-01 00: 00: 00.0000000”). Bir takvim gününü geçmeyecek şekilde taşındıklarında aynı 1 milisaniye tarih-saat farkı Day, 0 (gün) cinsinden "DateDiff" değerini döndürür .

2.2.3. almak Avgsadece geri tekrar birinci ve ardından “Float” dönüştürerek (bir Agrega Sorgusu) tarih-kez DateTime.

NOT: Bir sayıya dönüştürmek DateTime2için, aşağıdaki formül gibi, değerlerinizin 1970 yılından daha az olmadığını varsayalım (bu, tüm ekstra aralığı artı 217 yıl daha kaybettiğiniz anlamına gelir) Not: sayısal taşma sorunlarıyla karşılaşabileceğiniz için ekstra aralığa izin verecek şekilde formülü ayarlayamazsınız.

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

Tabii ki, aynı zamanda olabilir Castiçin DateTimeilk (ve gerekli tekrar etmek durumunda DateTime2), ancak hassasiyet ve aralık içinde (önceki tüm yıla 1753) faydalar kaybetmek istiyorum DateTime2vs. DateTimeprolly 2 büyük ve aynı zamanda prolly vardır büyük olasılıkla toplama / çıkarma / "yaş" (vs. DateDiff) / Avgcalcs faydası için kayan noktalı sayıya (gün sayısı) örtülü / kolay dönüşümleri kaybettiğinizde neden kullanmanız gerektiği sorusunu akla getiren en az gerekli olan 2 tecrübelerime göre.

Btw, Avgtarih saatlerinin önemli bir kullanım durumudur (veya en azından olmalıdır ). a) Tarih (genel bir temel tarih-saat) süreyi (ortak bir uygulama) temsil etmek için kullanıldığında ortalama sürenin kullanılmasının yanı sıra, b) ortalama tarihin ne olduğuna dair gösterge tablosu türü bir istatistik elde etmek de yararlıdır. saat, bir Satır aralığının / grubunun tarih-saat sütunundadır. c) Bir Sütundaki değerleri artık / artık geçerli olmayan ve / veya kullanımdan kaldırılması gerekebilecek değerleri izlemek / gidermek için standart (veya en azından standart olması gerekir) geçici bir Sorgu, her sayım için listelenen sayıyı listelemektir. ve (varsa) Min, Avgve Maxtarih-zaman damgaları bu değerle ilişkili.

Söz konusu alana Şimdi () yazmaya çalışan bir Access geliştiricisi iseniz DateTime2 hasara yol açar. Sadece Access -> SQL 2008 R2 geçişi yaptım ve tüm datetime alanlarını DateTime2 olarak koydu. Değer bombalanırken Now () ile bir kayıt eklemek. 01.01.2012 14:53:04, ancak 1/10/2012 14:53:04 tarihinde iyiydi.

Karakter bir kez fark yarattı. Umarım birine yardımcı olur.

Depolama boyutu (bayt) ve smalldatetime, datetime, datetime2 (0) ve datetime2 (7) arasındaki hassasiyetteki farklılıkları gösterecek bir örnek:

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

hangisi geri döner

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

Eğer bilgiyi ikinciye - ama milisaniyeye değil - saklamak istersem datetime veya datetime2 (7) yerine datetime2 (0) kullanırsam 2 bayt kaydedebilirim.

datetime2 ile artan hassasiyet olsa da , bazı istemciler tarih , saat veya datetime2'yi desteklemez ve sizi bir dizgi hazır bilgisine dönüştürmeye zorlar. Özellikle Microsoft, bu veri türleriyle "alt düzey" ODBC, OLE DB, JDBC ve SqlClient sorunlarından bahseder ve her birinin türü nasıl eşleyebileceğini gösteren bir grafiğe sahiptir .

Hassasiyet üzerinden değer uyumluluğu varsa datetime kullanın

Eski Soru ... Ama burada kimsenin belirtmediği bir şey eklemek istiyorum ... (Not: Bu benim kendi gözlemim, bu yüzden herhangi bir referans istemeyin)

Filtre ölçütlerinde kullanıldığında Datetime2 daha hızlıdır.

TLDR:

SQL 2016'da yüz bin satırlı bir tablo ve ENTY_TIME datetime sütunu vardı, çünkü tam zamanı saniyeler kadar saklamak gerekiyordu. Birçok birleşim ve bir alt sorgu ile karmaşık bir sorgu yürütürken, nerede yan tümcesi olarak kullandığımda:

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

Sorgu başlangıçta yüzlerce satır olduğunda iyiydi, ancak satır sayısı arttığında sorgu şu hatayı vermeye başladı:

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

Where yan tümcesini kaldırdım ve şimdi tüm tarihler için TÜM satırlar getirildi, ancak beklenmedik bir şekilde sorgu 1 saniye içinde çalıştırıldı. İç sorguyu nerede cümlesi ile çalıştırıyorum ve 85 saniye sürdü ve nerede madde olmadan 0.01 saniye sürdü.

Bentetime filtreleme performansı olarak bu konu için birçok konu ile karşılaştım

Sorguyu biraz optimize ettim. Ama elde ettiğim gerçek hız datetime sütununu datetime2 olarak değiştirmekti.

Şimdi daha önce zaman aşımına uğrayan aynı sorgu bir saniyeden daha az sürüyor.

şerefe

ABD dışındaki ayarları kullanırken tarih dizelerinin yorumlanması datetimeve datetime2farklı olması da farklı olabilir DATEFORMAT. Örneğin

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

Bu, 2013-05-06(yani 6 Mayıs) için datetimeve 2013-06-05(yani 5 Haziran ) için döner datetime2. Ancak, dateformatset ile mdy, hem @dve @d2dönüş 2013-06-05.

datetimeDavranış ile oran görünüyor MSDN belgelerine ait SET DATEFORMAT: devletler hangi örnek ISO 8601 için bağımsız DATEFORMAT ayarının yorumlanır, bazı karakter dizeleri formatları . Açıkçası doğru değil!

Bu kadar ısırılana kadar yyyy-mm-dd, dil / yerel ayarlara bakılmaksızın tarihlerin doğru işleneceğini her zaman düşünürdüm .

Bu makaleye göre , DateTime2'yi kullanarak DateTime'ın aynı hassasiyetine sahip olmak istiyorsanız, DateTime2'yi (3) kullanmanız yeterlidir. Bu size aynı hassasiyeti vermeli, daha az bayt almalı ve genişletilmiş bir aralık sağlamalıdır.

Ben sadece bir avantaj daha tökezledi DATETIME2: Python adodbapimodülünde, datetimebir DATETIMEsütun için sıfır olmayan mikrosaniye olan ancak sütun olarak tanımlanırsa iyi çalışır standart kitaplık değeri geçirilirse patlar bir hata önler DATETIME2.

Select ValidUntil + 1
from Documents

Yukarıdaki SQL bir DateTime2 alanı ile çalışmaz. "İşlenen türü çakışması: datetime2 int ile uyumsuz" hatası veriyor ve hata veriyor

Ertesi günü almak için 1 eklemek, geliştiricilerin yıllardır tarihlerle yaptıkları bir şeydir. Artık Microsoft'un bu basit işlevselliği işleyemeyen süper yeni bir datetime2 alanı var.

"Eskisinden daha kötü olan bu yeni türü kullanalım" diye düşünmüyorum!

Ben DATETIME2depolamak için daha iyi bir yol olduğunu düşünüyorum date, çünkü daha verimlidir DATETIME. Gelen SQL Server 2008kullanabilirsiniz DATETIME2, o bir tarih ve saat saklar 6-8 alır bytesdepolamak ve bir hassasiyete sahiptir 100 nanoseconds. Böylece daha fazla zaman hassasiyetine ihtiyaç duyan herkes isteyecektir DATETIME2.