Há algumas coisas a considerar aqui:
- A lista de atributos muda significativamente ao longo do tempo
- A lista de atributos requer atributos personalizados definidos pelo usuário
- Existem atributos diferentes para escolas diferentes (ou seja, muitos atributos se aplicam apenas a uma ou algumas escolas)?
Se alguma delas for verdadeira, você pode pensar em uma abordagem de loja de propriedades como EAV, hstore, json campos, campos xml, etc .
Caso contrário - se você tiver uma lista bastante estática de propriedades em que a maioria delas faz sentido para a maioria das linhas - não há realmente um problema em tê-las como 60 colunas individuais. Será mais fácil adicionar índices para conjuntos de atributos comumente pesquisados, incluindo índices parciais e compostos, etc., e as pesquisas - particularmente aquelas para muitos atributos diferentes - serão muito mais rápido.
Veja também:Design de banco de dados - devo usar 30 colunas ou 1 coluna com todos os dados em forma de JSON/XML ?
Há também uma opção de compromisso disponível para você:Uma tabela principal para os detalhes mais importantes que você procura muito, além de tabelas laterais para agrupamentos lógicos de atributos. Dizer:
yearly_summary (
yearly_summary_id serial primary key,
school_id integer,
total_students integer,
...
)
mais
yearly_student_stats(
yearly_summary_id integer primary key references yearly_summary(yearly_summy_id) on delete cascade,
...
)
etc. A
integer primary key isso também é uma foreign key significa que você tem um relacionamento 1:1 (opcional) obrigatório com a outra tabela. Essa abordagem pode ser útil se você tiver alguns agrupamentos lógicos de atributos que podem ser agrupados em tabelas complementares. Eu também ficaria surpreso se um pouco mais de reflexão não revelasse coisas que fazem faz sentido normalizar. Você tem
year7_blah , year8_blah , year9_blah etc colunas? Em caso afirmativo:Ótimo candidato para normalização. 
