Clairement, avec les éléments que tu nous donnes, les deux approches sont faisables.
Elles sont faisables, mais aucune ne me semble raisonnable, comme je disais dans mon commentaire ci-dessus :) Ca détruit l'intérêt de la colonne "mois" à chaque fois. Or, s'il est là, c'est qu'il y a peut-être une raison.
A la limite, ce qui me semblerait raisonnable s'il y a besoin de stocker les résultats sur plus d'une année, c'est altérer la table une bonne fois pour toute, pour rajouter une colonne année (voir un vrai champ date au lieu de deux colonnes... mais bon :) ça, c'est que du design !)
Là on pourrait éventuellement faire des stats en tranchant par mois, année, etc.
Mais les deux autres options vont en dépit du bon sens d'une base de donnée à mon avis (je ne suis ni SGBD admin, ni dans la mouvance noSQL, donc je peux me gourer sur les tendances modernes, hein !).
[^] # Re: Table
Posté par _kaos_ . En réponse au message Modifier le schema dynamiquement. Évalué à 1.
Hello,
Elles sont faisables, mais aucune ne me semble raisonnable, comme je disais dans mon commentaire ci-dessus :) Ca détruit l'intérêt de la colonne "mois" à chaque fois. Or, s'il est là, c'est qu'il y a peut-être une raison.
A la limite, ce qui me semblerait raisonnable s'il y a besoin de stocker les résultats sur plus d'une année, c'est altérer la table une bonne fois pour toute, pour rajouter une colonne année (voir un vrai champ date au lieu de deux colonnes... mais bon :) ça, c'est que du design !)
Là on pourrait éventuellement faire des stats en tranchant par mois, année, etc.
Mais les deux autres options vont en dépit du bon sens d'une base de donnée à mon avis (je ne suis ni SGBD admin, ni dans la mouvance noSQL, donc je peux me gourer sur les tendances modernes, hein !).
Matricule 23415