In veel gevallen hebben we zulke 'min of meer precieze' datums nodig, en ik gebruik datums als 2011-04-01 (precies), evenals 2011-04 (=april 2011) en 2011 (datum alleen voor het jaar) in metadata van archieven. Zoals je het zegt, het MySQL-datumveld tolereert '2011-00-00' hoewel er geen FAQ's over vertellen, en het is prima.
Maar toen moest ik de MySQL database koppelen via ODBC en de datumvelden zijn correct vertaald, behalve de 'getolereerde' datums (bijv. '2011-04-00' resultaten leeg in de resulterende MySQL-ODBC-verbonden ACCESS-database.
Om die reden kwam ik tot de conclusie dat het MySQL-datumveld kan worden omgezet in een gewone VARCHAR(10) field :Zolang we geen specifieke MySQL-datumfuncties nodig hebben, werkt het prima, en natuurlijk kunnen we nog steeds php-datumfuncties en je fijne date_php2mysql()-functie gebruiken.
Ik zou zeggen dat het enige geval waarin een MySQL-datumveld nodig is, is wanneer men complexe SQL-query's nodig heeft, met behulp van MySQL datumfuncties in de zoekopdracht zelf. (Maar dergelijke zoekopdrachten zouden niet meer werken op 'min of meer precieze' datums!...)
Conclusie :Voor 'min of meer precieze' datums negeer ik momenteel het MySQL-datumveld en gebruik ik gewoon VARCHAR(10) veldmet aaaa-mm-jj geformatteerde gegevens. Simpel is mooi.