In vielen Fällen benötigen wir solche „mehr oder weniger genauen“ Daten, und ich verwende solche Daten wie 2011-04-01 (genau), sowie 2011-04 (=April 2011) und 2011 (Nur-Jahres-Datum) in Archiv-Metadaten. Wie Sie bereits erwähnt haben, toleriert das MySQL-Datumsfeld '2011-00-00', obwohl keine FAQs darüber berichten, und es ist in Ordnung.
Aber dann musste ich die MySQL database anbinden über ODBC und die Datumsfelder sind korrekt übersetzt, mit Ausnahme der 'tolerierten' Daten (Bsp.:'2011-04-00' ergibt leer in der resultierenden MySQL-ODBC-verbundenen ACCESS-Datenbank.
Aus diesem Grund bin ich zu dem Schluss gekommen, dass das MySQL-Datumsfeld könnte in ein einfaches VARCHAR(10) umgewandelt werden field :Solange wir keine spezifischen MySQL-Datumsfunktionen benötigen, funktioniert es gut, und natürlich können wir immer noch PHP-Datumsfunktionen und Ihre gute Funktion date_php2mysql() verwenden.
Ich würde sagen, dass der einzige Fall, in dem ein MySQL-Datumsfeld benötigt wird, ist, wenn man komplexe SQL-Abfragen mit MySQL benötigt Datumsfunktionen in der Abfrage selbst. (Aber solche Abfragen würden bei 'mehr oder weniger genauen' Daten nicht mehr funktionieren!...)
Fazit :Für „mehr oder weniger genaue“ Daten verwerfe ich derzeit das MySQL-Datumsfeld und verwende einfach VARCHAR(10) Feld mit aaaa-mm-jj formatierte Daten. Einfach ist schön.
