Należy wziąć pod uwagę kilka rzeczy:
- Czy lista atrybutów zmienia się znacząco w czasie?
- Czy lista atrybutów wymaga niestandardowych atrybutów zdefiniowanych przez użytkownika?
- Czy istnieją różne atrybuty dla różnych szkół (tj. wiele atrybutów dotyczy tylko jednej lub kilku szkół)?
Jeśli którekolwiek z powyższych jest prawdziwe, możesz pomyśleć o podejściu do przechowywania właściwości takim jak EAV, hstore, json pola, pola xml itp. .
Jeśli nie – jeśli masz dość statyczną listę właściwości, w której większość z nich ma sens dla większości wierszy – to nie ma problemu z posiadaniem ich jako 60 osobnych kolumn. Łatwiejsze będzie dodawanie indeksów do często wyszukiwanych zestawów atrybutów, w tym indeksów częściowych i złożonych itp., a wyszukiwań - szczególnie tych dla wielu różnych atrybutów - będzie dużo szybciej.
Dostępna jest również opcja kompromisu:główna tabela z najważniejszymi szczegółami, które często przeglądasz, plus tabele boczne do logicznego grupowania atrybutów. Powiedz:
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,
...
)
itp. integer primary key to także foreign key oznacza, że istnieje wymuszona relacja 1:1 (opcjonalna) z drugą tabelą. Takie podejście może być przydatne, jeśli masz kilka logicznych grup atrybutów, które możesz pogrupować w tabele boczne.
Byłbym również zaskoczony, gdyby trochę więcej przemyśleń nie ujawniło rzeczy, które robi sensowna normalizacja. Czy masz year7_blah , year8_blah , year9_blah itp. kolumny? Jeśli tak:Świetny kandydat do normalizacji.
