En muchas ocasiones, necesitamos fechas 'más o menos precisas', y yo uso fechas como 2011-04-01 (preciso), así como 2011-04 (=abril de 2011) y 2011 (fecha solo del año) en los metadatos de los archivos. Como lo menciona, el campo de fecha de MySQL tolera '2011-00-00', aunque no hay preguntas frecuentes sobre esto, y está bien.
Pero luego, tuve que conectar la MySQL database a través de ODBC y los campos de fecha están traducidos correctamente, excepto las fechas 'toleradas' (Ej:'2011-04-00' resulta vacío en la base de datos ACCESS conectada a MySQL-ODBC resultante.
Por esa razón, llegué a la conclusión de que el campo de fecha de MySQL podría convertirse en un VARCHAR(10) simple field :Siempre que no necesitemos funciones de fecha específicas de MySQL, funciona bien y, por supuesto, aún podemos usar las funciones de fecha de php y su función date_php2mysql().
Diría que el único caso en el que se necesita un campo de fecha de MySQL es cuando se necesitan consultas SQL complejas, usando MySQL funciones de fecha en la consulta misma. (¡Pero tales consultas ya no funcionarían en fechas 'más o menos precisas'!...)
Conclusión :Para fechas 'más o menos precisas', actualmente descarto el campo de fecha de MySQL y uso VARCHAR(10) simple campo con aaaa-mm-jj datos formateados. Lo simple es hermoso.
