Dans de nombreuses occasions, nous avons besoin de telles dates "plus ou moins précises", et j'utilise des dates telles que 2011-04-01 (précis), ainsi que 2011-04 (=avril 2011) et 2011 (date de l'année uniquement) dans les métadonnées des archives. Comme vous le mentionnez, le champ de date MySQL tolère '2011-00-00' bien qu'aucune FAQ n'en parle, et ça va.
Mais ensuite, j'ai dû interfacer la MySQL database via ODBC et les champs de date sont correctement traduits, à l'exception des dates 'tolérées' (Ex :'2011-04-00' résultats vides dans la base de données ACCESS connectée à MySQL-ODBC résultante.
Pour cette raison, je suis arrivé à la conclusion que le champ de date MySQL pourrait être converti en un simple VARCHAR(10) field :Tant que nous n'avons pas besoin de fonctions de date MySQL spécifiques, cela fonctionne bien, et bien sûr, nous pouvons toujours utiliser les fonctions de date php et votre fonction fine date_php2mysql().
Je dirais que le seul cas où un champ de date MySQL est nécessaire est lorsque l'on a besoin de requêtes SQL complexes, en utilisant MySQL date fonctionne dans la requête elle-même.(Mais de telles requêtes ne fonctionneraient plus sur des dates 'plus ou moins précises' !...)
Conclusion :Pour les dates "plus ou moins précises", je supprime actuellement le champ de date MySQL et utilise simplement VARCHAR(10) champavec aaaa-mm-jj données formatées. La simplicité est belle.
