Hay algunas cosas a considerar aquí:
- ¿La lista de atributos cambia significativamente con el tiempo
- ¿La lista de atributos requiere atributos personalizados definidos por el usuario
- ¿Hay diferentes atributos para diferentes escuelas (es decir, muchos atributos solo se aplican a una o unas pocas escuelas)?
Si alguno de estos es cierto, podría pensar en un enfoque de tienda de propiedades como EAV, hstore, json campos, campos xml, etc .
De lo contrario, si tiene una lista bastante estática de propiedades donde la mayoría de ellas tienen sentido para la mayoría de las filas, entonces no hay ningún problema en tenerlas como 60 columnas individuales. Será más fácil agregar índices para conjuntos de atributos buscados comúnmente, incluidos índices parciales y compuestos, etc., y las búsquedas, en particular las de muchos atributos diferentes, serán muchas. más rápido.
Consulte también:Diseño de base de datos:¿debería usar 30 columnas o 1 columna con todos los datos en forma de JSON/XML? ?
También hay una opción de compromiso disponible para usted:una tabla principal para los detalles más importantes que busca con frecuencia, además de tablas auxiliares para agrupaciones lógicas de atributos. Di:
yearly_summary (
yearly_summary_id serial primary key,
school_id integer,
total_students integer,
...
)
más
yearly_student_stats(
yearly_summary_id integer primary key references yearly_summary(yearly_summy_id) on delete cascade,
...
)
etc. La integer primary key eso también es una foreign key significa que tiene una relación forzada 1:1 (opcional) con la otra tabla. Este enfoque puede ser útil si tiene algunas agrupaciones lógicas de atributos que puede agrupar en tablas auxiliares.
También me sorprendería si un poco más de reflexión no revelara cosas que hacen tiene sentido normalizar. ¿Tienes year7_blah? , year8_blah , year9_blah etc columnas? Si es así:Gran candidato para la normalización.
