I många tillfällen behöver vi sådana "mer eller mindre exakta" datum, och jag använder sådana datum som 2011-04-01 (exakt), samt 2011-04 (=april 2011) och 2011 (endast år) i arkivmetadata. Som du nämner det, tolererar MySQL-datumfältet '2011-00-00' även om inga vanliga frågor berättar om det, och det är bra.
Men då var jag tvungen att gränssnitta MySQL database via ODBC och datumfälten är korrekt översatta, förutom att de "tolererade" datumen (t.ex.:"2011-04-00" är tomma i den resulterande MySQL-ODBC-anslutna ACCESS-databasen.
Av den anledningen kom jag till slutsatsen att MySQL-datumfältet kan konverteras till en vanlig VARCHAR(10) field :Så länge vi inte behöver specifika MySQL-datumfunktioner fungerar det bra, och naturligtvis kan vi fortfarande använda php-datumfunktioner och din fine date_php2mysql()-funktion.
Jag skulle säga att det enda fallet när ett MySQL-datumfält behövs är när man behöver komplexa SQL-frågor med MySQL datum fungerar i själva frågan.(Men sådana frågor skulle inte fungera längre på "mer eller mindre exakta" datum!...)
Slutsats :För "mer eller mindre exakta" datum kasserar jag för närvarande MySQL-datumfältet och använder vanlig VARCHAR(10) fält med aaaa-mm-jj formaterad data. Enkelt är vackert.