Ada beberapa hal yang perlu dipertimbangkan di sini:
- Apakah daftar atribut berubah secara signifikan dari waktu ke waktu
- Apakah daftar atribut memerlukan atribut buatan pengguna khusus
- Apakah ada atribut yang berbeda untuk sekolah yang berbeda (yaitu banyak atribut hanya berlaku untuk satu atau beberapa sekolah)?
Jika salah satu dari ini benar, Anda mungkin berpikir tentang pendekatan toko properti seperti EAV, hstore, json bidang, bidang xml, dll .
Jika tidak - jika Anda memiliki daftar properti yang cukup statis di mana sebagian besar masuk akal untuk sebagian besar baris - maka sebenarnya tidak ada masalah dengan menjadikannya sebagai 60 kolom individual. Akan lebih mudah untuk menambahkan indeks untuk kumpulan atribut yang sering ditelusuri, termasuk indeks parsial dan komposit, dll, dan pencarian - terutama untuk banyak atribut yang berbeda - akan banyak lebih cepat.
Ada juga opsi kompromi yang tersedia untuk Anda:Tabel utama untuk detail terpenting yang sering Anda cari, ditambah tabel samping untuk pengelompokan atribut yang logis. Ucapkan:
yearly_summary (
yearly_summary_id serial primary key,
school_id integer,
total_students integer,
...
)
ditambah
yearly_student_stats(
yearly_summary_id integer primary key references yearly_summary(yearly_summy_id) on delete cascade,
...
)
dll. integer primary key itu juga foreign key berarti Anda memiliki hubungan 1:1 (opsional) yang dipaksakan ke tabel lainnya. Pendekatan ini dapat berguna jika Anda memiliki beberapa pengelompokan logis atribut yang dapat dikelompokkan ke dalam tabel samping.
Saya juga akan terkejut jika sedikit lebih banyak pemikiran tidak mengungkapkan hal-hal yang lakukan masuk akal untuk dinormalisasi. Apakah Anda memiliki year7_blah , year8_blah , year9_blah dll kolom? Jika demikian:Kandidat yang bagus untuk normalisasi.
