Adakah alasan bagus untuk menyimpan tanggal dan waktu di kolom terpisah?

Saya mencoba memahami keputusan vendor perangkat lunak kami untuk menjaga tanggal dan waktu dalam kolom terpisah. Misalnya, ketika baris dibuat atau diperbarui. Waktu dan tanggal adalah kolom DateTime. Kami menggunakan SQL Server 2005.

Basis data menyimpan data sistem ERP kami dan saya percaya tabel terbesar berisi sekitar ~ 3 juta baris. Sebagian besar tabel berkisar antara 100.000 - 1.000.000 baris.

Saya pribadi akan secara default memilih DateTime tunggal untuk cap waktu tunggal. Ini akan memungkinkan perhitungan perbedaan waktu yang lebih mudah dan bagian tanggal dan waktu dapat dengan mudah diekstraksi dari cap waktu. Itu juga akan mengkonsumsi lebih sedikit ruang.

Apakah memisahkan tanggal dan waktu merupakan praktik yang buruk atau ada sesuatu yang sangat brilian dalam desain ini yang saya tidak mengerti?

Dugaan saya adalah bahwa ini adalah hal yang mendukung warisan (yaitu kembali dalam versi 1 dari perangkat lunak mereka, mereka memiliki tanggal dan waktu di bidang yang terpisah dan mereka telah dipaksa untuk mendukungnya karena selalu bekerja seperti itu).

Yang mengatakan, tidak ada yang brilian tentang memisahkan tanggal dan waktu, jadi tidak ada yang Anda lewatkan.

(Pilihan lainnya adalah bahwa pengembang sistem ERP Anda tidak tahu bahwa bidang datetime dapat menyimpan tanggal dan waktu, tetapi jauh lebih mungkin adalah bahwa mereka memiliki persyaratan bisnis untuk membuatnya bekerja sama dengan versi sebelumnya.)

Secara umum, itu tergantung pada penggunaan. Jika banyak pertanyaan menggabungkan sub-elemen bersama maka pertimbangkan untuk menyimpannya bersama-sama dan kemudian mengambil biaya tambahan karena harus memecahnya pada kesempatan yang lebih jarang. Tentu saja, pemisahan terkadang lebih rumit (atau tidak mungkin): pertimbangkan person_full_nameatribut yang perlu Anda ekstrak person_family_name. Yang mengatakan, down casting nilai sementara itu sepele jadi saya biasanya lebih suka menyimpan tanggal dan waktu bersama.

Juga pertimbangkan untuk menyimpan keduanya bersama-sama DAN terpisah, dengan kendala (dan mungkin pemicu) untuk memastikan mereka tidak keluar dari sinkronisasi: cara ini Anda mengambil hit pemisahan / bergabung pada titik pembaruan daripada pada saat menanyakan pertanyaan data.

Saya tidak dapat melihat banyak kegunaan untuk ini dalam sistem operasional. Dalam sistem analitik, Anda mungkin menginginkan dimensi tanggal yang terpisah dengan butiran 'hari' sehingga tanggal tersebut terhubung ke pelaporan roll-up tanggal, dan mungkin kolom 'waktu' jika Anda ingin melakukan analisis berdasarkan waktu untuk suatu alasan .

Anda juga bisa menyajikan tanggal dan waktu sebagai kolom terhitung berdasarkan kolom datetime inti.

Untuk menambahkan komentar ConcernedOfTunbridgeWe, ada keuntungan kinerja kueri jika Anda memiliki tabel DateDimension dan TimeDimension. Pertimbangkan tabel fakta memiliki dateDimensionKey dan TimeDimensionKey. Jika Anda ingin menemukan jumlah antara pukul 8 pagi hingga 5 sore, Anda bisa melakukannya

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

Jika Anda memiliki indeks yang ditambahkan ke TimeDimensionKey, Anda hanya akan membutuhkan Pencarian Indeks untuk hasil pada tabel fakta Anda untuk mencari data

Tanpa tabel TimeDimension, Anda harus melakukan sesuatu seperti berikut ini,

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

Ini mungkin akan memerlukan pemindaian tabel karena mesin basis data perlu menghitung hasil untuk setiap baris sebelum dapat mengetahui data apa yang dapat dikembalikan.