Gibt es gute Gründe, Datum und Uhrzeit in getrennten Spalten zu halten?

Ich versuche, die Entscheidung unseres Softwareanbieters zu verstehen, Datum und Uhrzeit in separaten Spalten zu speichern. Zum Beispiel, wenn die Zeile erstellt oder aktualisiert wurde. Sowohl Uhrzeit als auch Datum sind DateTime-Spalten. Wir verwenden SQL Server 2005.

Die Datenbank enthält die Daten unseres ERP-Systems, und ich glaube, die größten Tabellen enthalten ungefähr 3 Millionen Zeilen. Die meisten Tabellen bestehen ungefähr zwischen 100 000 und 1 000 000 Zeilen.

Ich persönlich würde standardmäßig eine einzelne DateTime für einen einzelnen Zeitstempel auswählen. Dies würde einfachere Zeitdifferenzberechnungen ermöglichen und die Datums- und Zeitteile könnten leicht aus dem Zeitstempel extrahiert werden. Es würde auch weniger Platz verbrauchen.

Ist das Trennen von Datum und Uhrzeit eine schlechte Praxis oder gibt es etwas sehr Brillantes in diesem Design, das ich nicht verstehe?

Ich vermute, dass es sich um eine Legacy-Support-Sache handelt (dh in Version 1 ihrer Software hatten sie Datum und Uhrzeit in separaten Feldern und mussten sie unterstützen, weil es immer so funktioniert hat).

Das heißt, es ist nichts Geniales daran, Datum und Uhrzeit zu trennen, also fehlt Ihnen nichts.

(Die andere Option ist, dass Ihre ERP-Systementwickler nicht wussten, dass in einem Datums- / Uhrzeitfeld ein Datum und eine Uhrzeit gespeichert werden können. Es ist jedoch weitaus wahrscheinlicher, dass sie geschäftliche Anforderungen hatten, damit es genauso funktioniert wie frühere Versionen.)

Im Allgemeinen hängt es von der Verwendung ab. Wenn viele Abfragen Unterelemente miteinander verbinden, sollten Sie sie stattdessen zusammen speichern und dann den Aufwand übernehmen, sie bei diesen selteneren Gelegenheiten aufteilen zu müssen. Natürlich ist das Teilen manchmal komplexer (oder unmöglich): Betrachten Sie ein person_full_nameAttribut, aus dem Sie extrahieren müssen person_family_name. Das Herunterwerfen eines zeitlichen Werts ist jedoch trivial, daher würde ich es im Allgemeinen vorziehen, Datum und Uhrzeit zusammen zu speichern.

Ziehen Sie auch in Betracht, beide zusammen UND getrennt zu speichern, mit Einschränkungen (und möglicherweise Auslösern), um sicherzustellen, dass sie nicht nicht synchron sind: Auf diese Weise können Sie den Treffer beim Aufteilen / Verbinden zum Zeitpunkt der Aktualisierung und nicht zum Zeitpunkt der Abfrage des Daten.

Ich kann in einem Betriebssystem nicht viel Verwendung dafür sehen. In einem Analysesystem möchten Sie möglicherweise eine separate Datumsdimension mit einer Körnung von "Tagen", sodass das Datum mit der Meldung von Datums-Rollups verknüpft ist, und möglicherweise eine Spalte "Uhrzeit", wenn Sie aus irgendeinem Grund eine Analyse nach Tageszeit durchführen möchten .

Sie können Datum und Uhrzeit auch als berechnete Spalten basierend auf einer Kern-Datums- / Uhrzeitspalte darstellen.

Um den Kommentar von ConcernedOfTunbridgeWe zu ergänzen, gibt es einen Leistungsvorteil beim Abfragen, wenn Sie eine DateDimension- und eine TimeDimension-Tabelle haben. Beachten Sie, dass die Faktentabelle sowohl einen dateDimensionKey als auch einen TimeDimensionKey enthält. Wenn Sie die Nummer von etwas zwischen 8 und 17 Uhr finden möchten, können Sie dies einfach tun

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

Wenn Sie dem TimeDimensionKey einen Index hinzugefügt haben, benötigen Sie nur eine Indexsuche für das Ergebnis in Ihrer Faktentabelle, um Daten zu suchen

Ohne TimeDimension-Tabelle müssen Sie Folgendes tun:

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

Dies erfordert wahrscheinlich einen Tabellenscan, da das Datenbankmodul das Ergebnis für jede Zeile berechnen muss, bevor es herausfinden kann, welche Daten zurückgegeben werden können.