Zde je třeba zvážit několik věcí:
- Změní se seznam atributů významně v průběhu času
- Vyžaduje seznam atributů vlastní atributy definované uživatelem?
- Existují různé atributy pro různé školy? (tj. mnoho atributů se vztahuje pouze na jednu nebo několik škol)?
Pokud je některá z těchto skutečností pravdivá, můžete přemýšlet o přístupu obchodu s nemovitostmi jako EAV, hstore, json pole, pole xml atd .
Pokud ne – pokud máte poměrně statický seznam vlastností, kde většina z nich dává smysl pro většinu řádků – pak není problém mít je jako 60 jednotlivých sloupců. Bude snazší přidávat indexy pro běžně vyhledávané sady atributů, včetně částečných a složených indexů atd., a hledání – zejména pro mnoho různých atributů – bude velmi rychleji.
Viz také:Návrh databáze – mám použít 30 sloupců nebo 1 sloupec se všemi daty ve formátu JSON/XML ?
K dispozici máte také kompromisní možnost:Hlavní tabulka pro nejdůležitější detaily, které často vyhledáváte, plus vedlejší tabulky pro logické seskupení atributů. Řekněte:
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,
...
)
atd. integer primary key to je také foreign key znamená, že máte vynucený vztah 1:1 (volitelné) k druhé tabulce. Tento přístup může být užitečný, pokud máte několik logických seskupení atributů, které můžete seskupit do postranních tabulek.
Také bych se divil, kdyby trochu více zamyšlení neodhalilo věci, které dělají má smysl normalizovat. Máte year7_blah , year8_blah , year9_blah atd. sloupce? Pokud ano:Skvělý kandidát na normalizaci.