DateTime'ı depolamanın tercih edilen yolu

Tarih ve Saat bilgilerini birkaç şekilde saklayabiliriz. DateTime bilgilerini depolamak için en iyi yaklaşım nedir?

DateTime'ı kullanarak Tarih ve Saati 2 ayrı sütunda mı yoksa bir sütunda mı saklıyorsunuz ?

Bu yaklaşımın neden daha iyi olduğunu açıklayabilir misiniz?

^{(Referans için MySQL belgelerine bağlantı, soru geneldir, MySQL'e özgü değildir)
Tarih ve Saat türleri: Tarih ve Saat}

Verilerin tek bir sütunda depolanması, ayrılmaz bir şekilde bağlantılı oldukları için tercih edilen yoldur. Zamandaki nokta, iki değil, tek bir bilgidir.

Birçok ürün tarafından "perde arkasında" kullanılan tarih / saat verisini depolamanın yaygın bir yolu, "tarih" ondalık değerin tamsayı kısmı ve "saat" in kesirli olduğu ondalık bir değere dönüştürmektir. değer. Böylece, 1900-01-01 00:00:00 0.0, 20 Eylül 2016 9:34:00 42631.39861 olarak saklanır. 42631, 1900-01-01'den bu yana geçen gün sayısıdır. .39861, gece yarısından bu yana geçen süredir. Bunu yapmak için doğrudan ondalık türü kullanmayın, açık bir tarih / saat türü kullanın; buradaki amacım sadece bir örnek.

Verilerin iki ayrı sütunda depolanması, belirli bir zaman noktasının depolanan değerden daha erken veya daha sonra olup olmadığını görmek istediğinizde her iki sütun değerini birleştirmeniz gerektiği anlamına gelir.

Değerleri ayrı ayrı saklarsanız, algılanması zor "hatalara" rastlarsınız. Örneğin aşağıdakileri ele alalım:

IF OBJECT_ID('tempdb..#DT') IS NOT NULL
DROP TABLE #DT;
CREATE TABLE #DT
(
    dt_value DATETIME NOT NULL
    , d_value DATE NOT NULL
    , t_value TIME(0) NOT NULL
);


DECLARE @d DATETIME = '2016-09-20 09:34:00';

INSERT INTO #DT (dt_value, d_value, t_value)
SELECT @d, CONVERT(DATE, @d), CONVERT(TIME(0), @d);

SET @d = '2016-09-20 11:34:00';

INSERT INTO #DT (dt_value, d_value, t_value)
SELECT @d, CONVERT(DATE, @d), CONVERT(TIME(0), @d);

/* show all rows with a date after 2016-07-01 11:00 am */
SELECT *
FROM #DT dt
WHERE dt.dt_value >= '2016-07-01 11:00:00';

/* show all rows with a date after 2016-07-01 11:00 am */
SELECT *
FROM #DT dt
WHERE dt.d_value >= CONVERT(DATE, '2016-07-01')
    AND dt.t_value >= CONVERT(TIME(0), '11:00:00');

Yukarıdaki kodda, iki değerle dolduran bir test tablosu oluşturuyoruz, ardından bu verilere karşı basit bir sorgu gerçekleştiriyoruz. Birincisi SELECTher iki satırı da döndürür, ancak ikincisi SELECTyalnızca tek bir satır döndürür, bu da istenen sonuç olmayabilir:

Yorumlarda @ ypercube tarafından işaret edildiği gibi, değerlerin ayrı sütunlarda olduğu bir tarih / saat aralığını filtrelemenin doğru yolu:

WHERE dt.d_value > CONVERT(DATE, '2016-07-01') /* note there is no time component here */
    OR (
        dt.d_value = CONVERT(DATE, '2016-07-01') 
        AND dt.t_value >= CONVERT(TIME(0), '11:00:00')
    )

Analiz amacıyla ayrılmış zaman bileşenine ihtiyacınız varsa , değerin zaman bölümü için hesaplanmış, kalıcı bir sütun eklemeyi düşünebilirsiniz:

ALTER TABLE #DT
ADD dt_value_time AS CONVERT(TIME(0), dt_value) PERSISTED;

SELECT *
FROM #dt;

Kalıcı sütun daha sonra günün saatine göre hızlı çeşitlere vb. İzin verecek şekilde dizine eklenebilir.

Tarih ve saati görüntüleme amacıyla iki alana ayırmayı düşünüyorsanız, biçimlendirmenin sunucuda değil istemcide yapılması gerektiğini fark etmelisiniz.

Diğer cevaplara karşı muhalif bir görüş sunacağım.

Hem tarih hem de saat bileşenleri birlikte gerekliyse, yani bir girdi birini içeriyor ancak diğerini içermiyorsa geçersizdir (veya birinde NULL ise ancak diğerinde değil), o zaman bunu tek bir sütunda saklamak, diğerlerinde verilen nedenlerden dolayı mantıklıdır. Yanıtlar.

Bununla birlikte, bir veya iki bileşenin ayrı ayrı isteğe bağlı olması söz konusu olabilir . Bu durumda, tek bir sütunda saklamak yanlış olur. Bunu yapmak, NULL değerlerini keyfi bir şekilde göstermeye zorlar, örneğin zamanı 00:00:00 olarak depolamak.

Burada bir çift örnek var:

• Kilometre vergisi kesintileri için araç yolculuklarını kaydediyorsunuz. Yolculuğun kesin zamanını bilmek faydalı olacaktır, ancak bir çalışan bunu not etmediyse ve unutmuşsa, tarih hala kendi başına kaydedilmelidir (gerekli tarih, isteğe bağlı saat).

• İnsanların öğle yemeğini ne zaman yediğini öğrenmek için bir anket yapıyorsunuz ve katılımcılardan tarihler de dahil olmak üzere öğle saatlerinin bir örneğiyle bir form doldurmalarını istiyorsunuz. Bazıları tarihi doldurmakla uğraşmaz ve verileri gerçekten önemsediğiniz zamanlar (isteğe bağlı tarih, gerekli zaman) atmak istemezsiniz.

Alternatif yaklaşımlar için bu soruya bakınız .

Belirli bir işletme / uygulama talebi olmadıkça bunu her zaman tek bir sütun olarak saklamayı tercih ederim. Puanlarım aşağıdadır -

• Zaman damgasından zaman ayıklamak sorun değil
• İkisini birlikte depolayabiliyorsak neden sadece zaman için ekstra sütun eklemeliyiz?
• Bunu önlemek için, sorgulama yaptığınızda her seferinde Tarih ve Saat ekleyin.

SQL Server'da DataTime'ı tek bir alan olarak saklamak en iyisidir. DataTime sütununda bir dizin oluşturursanız, Tarih araması ve DateTime araması olarak kullanılabilir. Bu nedenle, belirli bir tarih için var olan tüm kayıtları sınırlamanız gerekirse, özel bir şey yapmanıza gerek kalmadan dizini kullanabilirsiniz. Zaman bölümünü sorgulamanız gerekiyorsa, aynı dizini kullanamazsınız ve bu nedenle günün saati hakkında DateTime'dan daha fazla önem verdiğiniz bir iş durumunuz varsa, oluşturmanız gerekeceğinden ayrı olarak saklamanız gerekir. üzerinde bir endeks ve performansı artırmak.

Gerçekten de, bunun için standart bir çapraz DBMS türü olmaması üzücü (INT ve VARCHAR gibi tamsayılar ve dize değerleri için). Şimdiye kadar tanıştığım 2 çapraz veritabanı yaklaşımı, DataTime değerlerini ISO 8601 (daha uygun, insan tarafından okunabilir) standardına göre biçimlendirilmiş dizeler olarak saklamak için VARCHAR / CHAR sütunlarını kullanıyor ve bunları POSIX zaman damgaları (daha fazla depolanıyor) olarak saklamak için BIGINT kullanıyor verimli, hızlı, matematiksel olarak daha kolay manipüle edilebilir).

Bir sürü şeyi okuduktan sonra, BIGINT'deki UTC Unix zamanı en uygun çözüm gibi görünüyor. Gerekirse saat dilimi depolama için VARCHAR'daki TZDB zaman çizelgesi kimliği. Birkaç argüman:

1. TIMESTAMP ve DATETIME, arka planda karmaşık ve net görünmeyen bir dizi dikkat çekici dönüşüm yapıyor. Sunucu yerel saatten UTC'ye veya bazen sunucu zamanına veya zamanına değil. Her fonksiyon için bir sürü gizli yük.

2. BIGINT (8kb), neredeyse MySQL tarafından iki INT + bir şey olarak depolanan xxxxxx.xxxxxx biçiminde depolama için gereken en az DECIMAL kadar hafif veya daha hafiftir . Ve yüzyıllar öncesini depolamak yeterlidir.

3. Hemen hemen tüm büyük programlama dillerinde Unix zamanı ile çalışmak için standart fonksiyon kütüphaneleri bulunur.

4. BIGINT ile matematik işlemleri, herhangi bir donanımdaki diğer her şeyden daha hızlı veya daha hızlı olmalıdır.

Elbette yukarıdakilerin hepsi büyük, uluslararası projelerle ilgilidir. Küçük bir şey için, seçilen çerçevenin varsayılan formatıyla devam etmek yeterince iyi görünüyor.