ここで考慮すべきことがいくつかあります：
- 属性のリストは時間の経過とともに大幅に変化しますか
- 属性のリストにはカスタムユーザー定義属性が必要ですか？
- 学校ごとに異なる属性があります （つまり、多くの属性は1つまたは少数の学校にのみ適用されます）？
これらのいずれかに該当する場合は、EAV、hstore、jsonなどのプロパティストアアプローチを検討してください。フィールド、xmlフィールドなど 。
そうでない場合（ほとんどの行に対してほとんどのプロパティが意味をなす、かなり静的なプロパティのリストがある場合）、それらを60の個別の列として持つことに実際には問題はありません。部分インデックスや複合インデックスなど、一般的に検索される属性のセットにインデックスを追加する方が簡単で、検索（特に多くの異なる属性の検索）は多くになります。 より速く。
参照：データベースの設計-30列または1列を使用してすべてのデータをJSON/XML形式で使用する必要があります？
利用可能な妥協オプションもあります。よく調べる最も重要な詳細のメインテーブルと、属性の論理グループのサイドテーブルです。説明：
yearly_summary (
yearly_summary_id serial primary key,
school_id integer,
total_students integer,
...
)
プラス
yearly_student_stats(
yearly_summary_id integer primary key references yearly_summary(yearly_summy_id) on delete cascade,
...
)
など。integer primary key これはforeign keyでもあります 他のテーブルと1：1（オプション）の関係が強制されていることを意味します。このアプローチは、サイドテーブルにクラスター化できる属性の論理グループがいくつかある場合に役立ちます。
もう少し考えても、 することを明らかにしなかったとしても、私は驚きます。 正規化するのは理にかなっています。 year7_blahはありますか 、year8_blah 、year9_blah などの列？もしそうなら：正規化の素晴らしい候補。