Tarih ve saati ayrı sütunlarda tutmak için iyi bir neden var mı?

Yazılım satıcımızın tarih ve saati ayrı sütunlarda tutma kararını anlamaya çalışıyorum. Örneğin, satır oluşturulduğunda veya güncellendiğinde. Hem saat hem de tarih DateTime sütunlarıdır. SQL Server 2005 kullanıyoruz.

Veritabanı ERP sistemimizin verilerini tutar ve en büyük tabloların yaklaşık ~ 3 milyon satır içerdiğine inanıyorum. Tabloların çoğu kabaca 100 000-1000 000 arasındadır.

Şahsen ben varsayılan olarak tek bir zaman damgası için tek bir DateTime seçin. Bu, zaman farkı hesaplamalarının daha kolay olmasını sağlar ve tarih ve saat bölümleri zaman damgasından kolayca çıkarılabilir. Ayrıca daha az yer kaplardı.

Tarih ve saati ayırmak kötü bir uygulama mı yoksa anlamadığım bu tasarımda çok parlak bir şey var mı?

Tahminimce bu eski bir destek şeyidir (yani, yazılımlarının 1. sürümünde, ayrı alanlarda tarih ve saatleri vardı ve bunu her zaman bu şekilde çalıştığı için desteklemeye zorlandılar).

Bununla birlikte, tarih ve saati ayırmak konusunda parlak bir şey yok, bu yüzden kaçırdığınız hiçbir şey yok.

(Diğer seçenek, ERP sistem geliştiricilerinizin datetime alanının bir tarih ve saat depolayabileceğini bilmemesi , ancak daha önceki sürümlerle aynı şekilde çalışması için bir iş gereksinimi olmalarıdır.)

Genellikle kullanıma bağlıdır. Birçok sorgu alt öğelere birlikte katılıyorsa, bunları birlikte depolamayı düşünün ve daha nadir durumlarda bunları ayırmak zorunda kaldığınız yükü alın. Elbette, bölme bazen daha karmaşık (veya imkansız): person_full_nameçıkarmanız gereken bir niteliği düşünün person_family_name. Bununla birlikte, zamansal bir değer düşürmek önemsizdir, bu yüzden genellikle tarih ve saati birlikte depolamayı tercih ederim.

Ayrıca senkronizasyondan çıkmamalarını sağlamak için kısıtlamaları (ve belki de tetikleyicileri) hem birlikte hem de ayrı bir yerde saklamayı düşünün: bu şekilde, veri.

Operasyonel bir sistemde bunun için çok fazla kullanım göremiyorum. Analitik bir sistemde, 'günler' damgasına sahip ayrı bir tarih boyutu isteyebilirsiniz, bu nedenle tarih, rapor toplama tarihlerine bağlanır ve belki de herhangi bir nedenle günün saatine göre analiz yapmak istiyorsanız bir 'zaman' sütunu .

Ayrıca, tarih ve saati çekirdek datetime sütununa göre hesaplanmış sütunlar olarak da sunabilirsiniz.

ConcernedOfTunbridgeWe'nin yorumuna eklemek için bir DateDimension ve TimeDimension tablonuz varsa sorgulama performansı avantajı vardır. Olgu tablosunun hem dateDimensionKey hem de TimeDimensionKey öğelerine sahip olduğunu düşünün. Eğer sabah 8'den akşam 5'e kadar bir şey bulmak istiyorsanız,

SELECT COUNT(1) FROM FactTable f Inner Join TimeDimension t on f.TimeDimensionKey = t.TimeDimension WHERE t.Hour BETWEEN 8 AND 17.

TimeDimensionKey'e bir dizin eklediyseniz, veri tablonuzdaki verileri aramak için yalnızca bir Dizin Araması yapmanız gerekir

TimeDimension tablosu olmadan, aşağıdakine benzer bir şey yapmanız gerekecek,

SELECT COUNT(1) FROM FactTable f WHERE DatePart(mintue, f.Date) BETWEEN 8 AND 17

Bu muhtemelen bir tablo taraması gerektirecektir, çünkü veritabanı motorunun hangi verilerin döndürülebileceğini anlayabilmesi için önce her satır için sonucu hesaplaması gerekir.