Ich stelle einen Tisch auf, wo ich das Jahr und den Monat brauche. In MySQL glaube ich, dass ich 2 Optionen habe: (1) 2 Felder: 1 für das Jahr, 1 für den Monat oder (2) ein Datumsfeld (der Tag wäre immer 1).
Die beiden Felder haben den Vorteil, dass sie etwas schneller sind (glaube ich), weil MySQL den Wert nicht von einem Datum in eine ganze Zahl konvertieren muss, obwohl dies wahrscheinlich vernachlässigbar ist. Das Datumsfeld hat den Vorteil der "automatischen" Validierung: Jemand kann keine Daten in die Datenbank mit dem Monat 13 oder dem Jahr 1 erhalten. Mit einem Datumsfeld können Sie auch Datumsberechnungen einfacher durchführen (dh Monate dazwischen) ).
Was würdest du benutzen? Oder gibt es einen anderen, den du benutzen würdest?
Verwenden Sie ein Datumsfeld. Da sql nativ Datumsfelder unterstützt, ist es einfach, mithilfe der WHERE-Klausel nach bestimmten Daten zu filtern.
Die beiden Felder haben den Vorteil, dass sie etwas schneller sind [...]
Ihre SELECT-Abfrage ist nicht Ihr Engpass, also sollten Sie sich nicht darum kümmern. Lesbarkeit und ein pragmatisches Programm sind wichtiger als ein "wahrgenommener Engpass".
Ich würde separate Spalten verwenden, hauptsächlich weil das eine bessere Verwendung von Indizes ermöglichen würde. Zum Beispiel glaube ich nicht, dass ein Index für eine Datetime-Spalte helfen wird, wenn Sie nur mit Daten von einem bestimmten Monat (nicht Jahr) beschäftigt sind.
Obwohl IBM Informix Dynamic Server nicht sofort für Sie geeignet ist, unterstützt es den folgenden Typ:
%Vor%Dies speichert genau das, was Sie wollen - das Jahr und den Monat. Es hat seine Verwendung. Die DATETIME-Typenfamilie umfasst viele andere Typen, die gelegentlich verwendet werden können - und einige, die von Grenznutzen sind, das kanonische Beispiel ist DATETIME MONTH TO MINUTE. (Der Nachteil des Typs sind die ausführlichen Notationen, die für die Manipulation erforderlich sind. Es gibt jedoch viele Operationen, die für einen oder alle der DATETIME-Typen ausgeführt werden können.)
In vielen DBMS können Sie Constraints für Spalten platzieren. Wenn Sie also einen zweispaltigen Ansatz verwenden, platzieren Sie eine CHECK(month_column BETWEEN 1 AND 12) -Einschränkung für die Spalte, um sicherzustellen, dass der Benutzer keinen ungültigen Wert in die Tabelle eingegeben hat . Sie könnten sogar eine Einschränkung für die Jahresspalte anwenden.
Außerdem können Sie mit einigen DBMS benutzerdefinierte Typen erstellen, und ein Jahr-Monat-Typ ist ziemlich einfach, da diese gehen. Die Details hängen natürlich vom DBMS ab.
Wenn es keinen besonderen Leistungsvorteil gibt, Jahr und Monat getrennt zu speichern, würde ich bei dem Datum bleiben. Wenn Sie bei der Indexierung zwei Spalten haben, müssen Sie einen Index für die Kombination von Spalten und nicht für die Datumsspalte erstellen. Das Datum wird intern in einen langen Wert konvertiert, sodass der erforderliche Speicherplatz nicht wirklich ein Problem darstellt.
Denken Sie außerdem an den möglichen Erhaltungsschmerz mit zwei Feldern. Sie hätten zwei Datenbankfelder, möglicherweise zwei Felder auf einem Objekt oder die Notwendigkeit, Monat und Jahr zu / von der Datenbank zu erstellen / analysieren. Halten Sie es einfach mit einem Datum und lassen Sie die DB Ihre Datenintegrität überwachen.
Ich arbeite mit Daten wie Sie beschrieben - Ablaufdaten, wobei Tag immer letzter Tag des Monats ist, also brauchen wir nur Monat und Jahr. Wir speichern diese als Datum.
Wenn Sie Anfragen des Formulars "Gib alle Zeilen im Juli, unabhängig vom Jahr" erwarten, sind sie etwas einfacher mit separaten Spalten für Monat und Jahr zu schreiben. Ein separater Index für die Monatsspalte sollte es bissig machen.
Ansonsten würde ich für die einzelne Datumsspalte gehen: einfache, verständliche, eingebaute Validierungs- und Datumsmathematikfunktionen funktionieren. Ihre einzige Sorge ist, dass jemand, der neu im Design ist, sich fragen wird, warum alles immer am ersten Tag des Monats auftritt.
Es gibt noch einen weiteren Grund, separate Spalten für Monat und Jahr zu verwenden, auf die ich gestoßen bin: wenn der Monat nicht bekannt ist. Ich habe das für Apps verwendet, die eine bevorstehende Veranstaltung "irgendwann 2009" ermöglichen. In diesem Fall löst die Verwendung eines NULL in der Spalte "Monat" das Problem gut. Es gibt keinen einfachen Weg, dies mit einer Datumsspalte zu tun, es sei denn, Sie haben einen schrecklichen Hack, wie der 2. Januar, bedeutet, dass der Monat unbekannt ist.
Denken Sie einmal darüber nach: Eines Tages wird jemand zu Ihnen kommen mit der Forderung, die Anwendung mit der Fähigkeit zu verbessern, nicht nur Jahr und Monat, sondern auch einen Tag einzusparen. Würden Sie dann für einen Tag eine zusätzliche Spalte hinzufügen? Und dann, als nächstes möchten sie vielleicht, dass Sie auch Zeit sparen.
Wie einfach wäre es, die Funktionalität zu erweitern, wenn Sie separate Spalten für Jahr / Monat / Tag haben? Wenn Sie eine einzelne Datumsspalte haben?
Ich würde allein aus diesem Grund für eine Datumspalte gehen.
Wenn Sie viele Operationen für das Datumsfeld ausführen möchten, würde ich es in separate Spalten zerlegen und die Datenüberprüfung entweder in einer Tabellenbedingung oder in der DAL durchführen.
Zum Beispiel ist die Erstellung von Verkaufsberichten nach Tag, Monat und Jahr viel effizienter, wenn die Felder geteilt werden. Der Grund dafür ist, dass Sie keine Datetime-Funktionen verwenden müssen, um das Gruppierungsdatum zu zerlegen.
Wenn es so etwas wie ein Geburtstag ist, an dem ich es ab und zu abfragen könnte, würde ich mir darüber keine Sorgen machen und es einfach in einem Datumsfeld belassen.
Wahrscheinlich nicht, weil der kleinste Datetime-Datentyp in SQL Server (Microsoft) smalldatetime ist, der 4 Byte lang ist. Wenn Sie nur Monat und Jahr benötigen, benötigen Sie 1 Byte für den Monat und 2 Byte für das Jahr.
Tags und Links sql mysql database database-design