I mange tilfælde har vi brug for sådanne 'mere eller mindre præcise' datoer, og jeg bruger sådanne datoer som 2011-04-01 (præcis), samt 2011-04 (=april 2011) og 2011 (dato kun år) i arkivmetadata. Som du nævner det, tolererer MySQL-datofeltet '2011-00-00', selvom ingen ofte stillede spørgsmål fortæller om det, og det er fint.
Men så var jeg nødt til at forbinde MySQL database via ODBC og datofelterne er korrekt oversat, bortset fra de 'tolererede' datoer (eks.:'2011-04-00' resultater tomme i den resulterende MySQL-ODBC-forbundne ACCESS-database.
Af den grund kom jeg til den konklusion, at MySQL-datofeltet kunne konverteres til en almindelig VARCHAR(10) field :Så længe vi ikke har brug for specifikke MySQL-datofunktioner, fungerer det fint, og vi kan selvfølgelig stadig bruge php-datofunktioner og din fine date_php2mysql()-funktion.
Jeg vil sige, at det eneste tilfælde, hvor et MySQL-datofelt er nødvendigt, er, når man har brug for komplekse SQL-forespørgsler ved hjælp af MySQL dato fungerer i selve forespørgslen.(Men sådanne forespørgsler ville ikke fungere længere på 'mere eller mindre præcise' datoer!...)
Konklusion :For "mere eller mindre præcise" datoer kasserer jeg i øjeblikket MySQL-datofeltet og bruger almindeligt VARCHAR(10) felt med aaaa-mm-jj formaterede data. Enkelt er smukt.