Il y a quelques points à considérer ici :
- La liste des attributs change-t-elle de manière significative au fil du temps
- La liste des attributs nécessite-t-elle des attributs personnalisés définis par l'utilisateur
- Existe-t-il différents attributs pour différentes écoles (c'est-à-dire que de nombreux attributs ne s'appliquent qu'à une ou quelques écoles) ?
Si l'un de ces éléments est vrai, vous pourriez penser à une approche de magasin de propriétés comme EAV, hstore, json champs, champs xml, etc .
Sinon - si vous avez une liste assez statique de propriétés où la plupart d'entre elles ont un sens pour la plupart des lignes - alors il n'y a pas vraiment de problème à les avoir sous forme de 60 colonnes individuelles. Il sera plus facile d'ajouter des index pour les ensembles d'attributs couramment recherchés, y compris les index partiels et composites, etc., et les recherches - en particulier celles pour de nombreux attributs différents - seront beaucoup plus rapide.
Une option de compromis s'offre également à vous :une table principale pour les détails les plus importants que vous recherchez souvent, ainsi que des tables secondaires pour les regroupements logiques d'attributs. Dites :
yearly_summary (
yearly_summary_id serial primary key,
school_id integer,
total_students integer,
...
)
plus
yearly_student_stats(
yearly_summary_id integer primary key references yearly_summary(yearly_summy_id) on delete cascade,
...
)
etc. La integer primary key c'est aussi une foreign key signifie que vous avez une relation forcée 1:1 (facultative) avec l'autre table. Cette approche peut être utile si vous disposez de quelques regroupements logiques d'attributs que vous pouvez regrouper dans des tables annexes.
Je serais également surpris si un peu plus de réflexion ne révélait pas des choses qui font logique de normaliser. Avez-vous year7_blah , year8_blah , year9_blah colonnes etc? Si oui :excellent candidat pour la normalisation.
