Hier sind einige Dinge zu beachten:
- Ändert sich die Liste der Attribute im Laufe der Zeit wesentlich
- Erfordert die Liste der Attribute benutzerdefinierte benutzerdefinierte Attribute
- Gibt es unterschiedliche Attribute für verschiedene Schulen (d.h. viele Attribute gelten nur für eine oder wenige Schulen)?
Wenn einer dieser Punkte zutrifft, könnten Sie über einen Property-Store-Ansatz nachdenken wie EAV, hstore, json Felder, XML-Felder usw. .
Wenn nicht – wenn Sie eine ziemlich statische Liste von Eigenschaften haben, von denen die meisten für die meisten Zeilen sinnvoll sind – dann gibt es kein wirkliches Problem damit, sie als 60 einzelne Spalten zu haben. Es wird einfacher, Indizes für häufig gesuchte Sätze von Attributen hinzuzufügen, einschließlich partieller und zusammengesetzter Indizes usw., und die Suche - insbesondere nach vielen verschiedenen Attributen - wird viel sein schneller.
Siehe auch:Datenbankdesign - soll ich 30 Spalten oder 1 Spalte mit allen Daten in Form von JSON/XML verwenden ?
Es steht Ihnen auch eine Kompromissoption zur Verfügung:Eine Haupttabelle für die wichtigsten Details, nach denen Sie häufig suchen, sowie Nebentabellen für logische Gruppierungen von Attributen. Sagen Sie:
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,
...
)
usw. Der integer primary key das ist auch ein foreign key bedeutet, dass Sie eine erzwungene 1:1-Beziehung (optional) zur anderen Tabelle haben. Dieser Ansatz kann nützlich sein, wenn Sie einige logische Gruppierungen von Attributen haben, die Sie in Nebentabellen gruppieren können.
Ich wäre auch überrascht, wenn ein wenig mehr Nachdenken nicht Dinge enthüllen würde, die tun sinnvoll zu normalisieren. Haben Sie year7_blah , year8_blah , year9_blah etc Spalten? Wenn ja:Großartiger Kandidat für die Normalisierung.
