Det finns några saker att tänka på här:
- Ändras listan över attribut avsevärt över tiden
- Kräver listan med attribut anpassade användardefinierade attribut
- Finns det olika attribut för olika skolor (dvs många attribut gäller bara en eller ett fåtal skolor)?
Om något av dessa stämmer kanske du funderar på en fastighetsbutik som EAV, hstore, json fält, xml-fält, etc .
Om inte - om du har en ganska statisk lista över egenskaper där de flesta av dem är meningsfulla för de flesta raderna - så är det egentligen inga problem med att ha dem som 60 individuella kolumner. Det blir lättare att lägga till index för vanliga sökningar efter uppsättningar av attribut, inklusive partiella och sammansatta index, etc, och sökningar - särskilt de för många olika attribut - kommer att vara mycket snabbare.
Se även:Databasdesign – ska jag använda 30 kolumner eller 1 kolumn med all data i form av JSON/XML ?
Det finns också ett kompromissalternativ tillgängligt för dig:En huvudtabell för de viktigaste detaljerna du letar upp mycket, plus sidotabeller för logiska grupperingar av attribut. Säg:
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. integer primary key det är också en foreign key betyder att du har ett påtvingat 1:1 (valfritt) förhållande till den andra tabellen. Det här tillvägagångssättet kan vara användbart om du har några logiska grupperingar av attribut som du kan gruppera i sidotabeller.
Jag skulle också bli förvånad om lite mer eftertanke inte avslöjade saker som gör vettigt att normalisera. Har du year7_blah , year8_blah , year9_blah etc kolumner? Om så är fallet:Bra kandidat för normalisering.