Je suis également un adepte du timestamp (donc stockage en int) au lieu des dates. Seulement pour la raison que manipuler un entier c'est plus simple que d'en manipuler 3 (jour, mois, an) voir 5 ou 6 (heure, minute et éventuellement secondes).
Avec le format date, on est toujours à se demander où est le jour et le mois, avec ces fichues différences selon la langue d'install de l'OS ou du SGBD. Parfois même une extraction d'une base pour la remonter sur une autre va "inverser" mois/jour dans toutes les dates, l'horreur.
Ensuite, j'ai eu pour ma part d'énormes soucis à cause des fuseaux horaires, qui poussent à faire des conversions vers un fuseau de référence, qui fait qu'on se demande toujours si l'heure est au format local ou GMT ou autre... Et alors quand arrive les changements d'heures d'été/hivers alors là, on sait plus où on en est.
Avec les fonctions d'affichage/calcul de date côté PHP ou MySQL, ça revient un peu au même d'utiliser un format de stockage date ou entier. A ce que j'ai pu en constater, jamais vu de différence notable entre le travail pour utiliser l'un et le travail pour utiliser l'autre.
Pour moi le timestamp a deux défauts : d'une part c'est pas lisible dans les résultats quand tu fais tes requetes manuelles dans la base (mais franchement vous en faites souvent des requetes directes ? si oui, vous pensez pas que ça vaudrait le coup d'automatiser un peu ?).
D'autre part, il faut faire attention aux additions/soustractions avec les décalages horaires d'été et hivers, donc bien les traiter comme timestamp et pas comme entier lors d'addition/soustraction.
Avec le format date, on est toujours à se demander où est le jour et le mois, avec ces fichues différences selon la langue d'install de l'OS ou du SGBD. Parfois même une extraction d'une base pour la remonter sur une autre va "inverser" mois/jour dans toutes les dates, l'horreur.
Ensuite, j'ai eu pour ma part d'énormes soucis à cause des fuseaux horaires, qui poussent à faire des conversions vers un fuseau de référence, qui fait qu'on se demande toujours si l'heure est au format local ou GMT ou autre... Et alors quand arrive les changements d'heures d'été/hivers alors là, on sait plus où on en est.
Avec les fonctions d'affichage/calcul de date côté PHP ou MySQL, ça revient un peu au même d'utiliser un format de stockage date ou entier. A ce que j'ai pu en constater, jamais vu de différence notable entre le travail pour utiliser l'un et le travail pour utiliser l'autre.
Pour moi le timestamp a deux défauts : d'une part c'est pas lisible dans les résultats quand tu fais tes requetes manuelles dans la base (mais franchement vous en faites souvent des requetes directes ? si oui, vous pensez pas que ça vaudrait le coup d'automatiser un peu ?).
D'autre part, il faut faire attention aux additions/soustractions avec les décalages horaires d'été et hivers, donc bien les traiter comme timestamp et pas comme entier lors d'addition/soustraction.