Недостатки таблицы с большим количеством столбцов

У меня есть некоторые данные, которые мне нужно поместить в базу данных PostgreSQL. Эти данные относятся к школам. Таким образом, есть много атрибутов, касающихся школы, в основном маленькие целые числа, числа с плавающей запятой или небольшие тексты. И все данные меняются ежегодно. Итак, я создаю сущность под названием YearlyData и положить там атрибуты. Но дело в том, что количество атрибутов составляет около 50-60. Теперь их нельзя нормализовать, потому что они являются явными атрибутами самой школы. Поэтому я этически не могу разделить их на таблицы. Но я не уверен, что это повредит моей работе.

Я могу попытаться классифицировать эти данные и поместить их в отдельные таблицы и указать на них из YearlyData Таблица. Но тогда попытка поиска школ с параметрами 20-30+ приведет к безумному количеству объединений, я полагаю. Я также не уверен, повредит ли это моей работе.

Любой экспертный совет?

Источник

2 ответа

Решение

Здесь нужно учесть несколько вещей:

  • Значительно ли меняется список атрибутов с течением времени
  • Требует ли список атрибутов пользовательских пользовательских атрибутов?
  • Существуют ли разные атрибуты для разных школ (т.е. многие атрибуты применимы только к одной или нескольким школам)?

Если что-то из этого верно, вы можете подумать о подходе хранилища свойств , таком как EAV, hstore, поля json, поля xml и т. Д.

Если нет - если у вас есть довольно статичный список свойств, большинство из которых имеют смысл для большинства строк, - то на самом деле нет проблемы с тем, чтобы их было 60 отдельных столбцов. Будет проще добавить индексы для часто используемых наборов атрибутов, включая частичные и составные индексы и т. Д., И поиск, особенно по многим различным атрибутам, будет намного быстрее.

См. Также: Дизайн базы данных - я должен использовать 30 столбцов или 1 столбец со всеми данными в форме JSON/XML?

Вам также доступен вариант компромисса: главная таблица для наиболее важных деталей, которые вы часто просматриваете, а также дополнительные таблицы для логической группировки атрибутов. Сказать:

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 и т. д. столбцы? Если так: отличный кандидат для нормализации.

Источник

PostgreSQL хранит строки на так называемых страницах данных размером 8 КБ. Вы можете думать о них как о контейнерах с ограничением конечного размера. Недостатком широких строк является то, что база данных может умещаться в меньшем количестве строк на странице данных. Механизм базы данных быстрее возвращает 1000 строк с одной страницы, чем 1000 строк, распределенных по нескольким страницам. В этом случае один читается против 1000 с дисковым вводом-выводом, являющимся вашим врагом. Это то, что нужно знать, чтобы не избежать. Часто нужны широкие столы, с которыми можно справиться. В вашем случае вы будете использовать примерно 240 байт на строку (4 байта на целое число * 60 строк).

Источник
Другие вопросы по тегам