In molte occasioni, abbiamo bisogno di date "più o meno precise" e io uso date come 2011-04-01 (preciso), nonché 2011-04 (=aprile 2011) e 2011 (data del solo anno) nei metadati degli archivi. Come dici tu, il campo della data MySQL tollera "2011-00-00" anche se nessuna FAQ ne parla, e va bene.
Ma poi, ho dovuto interfacciare il MySQL database tramite ODBC e i campi della data sono tradotti correttamente, ad eccezione delle date "tollerate" (es:"2011-04-00" risulta vuoto nel database ACCESS connesso a MySQL-ODBC risultante.
Per questo motivo, sono giunto alla conclusione che il campo della data MySQL potrebbe essere convertito in un semplice VARCHAR(10) campo :Finché non abbiamo bisogno di funzioni di data MySQL specifiche, funziona bene e, naturalmente, possiamo ancora usare le funzioni di data php e la tua funzione fine date_php2mysql().
Direi che l'unico caso in cui è necessario un campo data MySQL è quando sono necessarie query SQL complesse, utilizzando MySQL date funzioni nella query stessa.(Ma tali query non funzionerebbero più su date "più o meno precise"!...)
Conclusione :Per date "più o meno precise", attualmente elimino il campo della data MySQL e utilizzo il semplice VARCHAR(10) campo con aaaa-mm-jj dati formattati. Semplice è bello.
