Тук трябва да имате предвид няколко неща:
- Списъкът с атрибути променя ли се значително с времето
- Списъкът с атрибути изисква ли персонализирани атрибути, дефинирани от потребителя
- Има ли различни атрибути за различните училища (т.е. много атрибути се отнасят само за едно или няколко училища)?
Ако някое от тези е вярно, може да помислите за подход за съхранение на свойства като EAV, hstore, json полета, xml полета и др .
Ако не - ако имате доста статичен списък със свойства, където повечето от тях имат смисъл за повечето от редовете - тогава всъщност няма проблем да ги имате като 60 отделни колони. Ще бъде по-лесно да добавяте индекси за често търсени набори от атрибути, включително частични и съставни индекси и т.н., а търсенията - особено тези за много различни атрибути - ще бъдат много по-бързо.
Има и компромисна опция, достъпна за вас:основна таблица за най-важните подробности, които търсите често, плюс странични таблици за логическо групиране на атрибути. Кажете:
yearly_summary (
yearly_summary_id serial primary key,
school_id integer,
total_students integer,
...
)
плюс
yearly_student_stats(
yearly_summary_id integer primary key references yearly_summary(yearly_summy_id) on delete cascade,
...
)
и т.н. integer primary key това също е foreign key означава, че имате наложена връзка 1:1 (по избор) към другата таблица. Този подход може да бъде полезен, ако имате няколко логически групи от атрибути, които можете да групирате в странични таблици.
Също така бих се изненадал, ако малко повече размисъл не разкрие неща, които правят има смисъл да се нормализира. Имате ли year7_blah , year8_blah , year9_blah и т.н. колони? Ако е така:Страхотен кандидат за нормализиране.
