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

Question

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

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

Любые консультации экспертов?

Answer 1

Есть несколько вещей, чтобы рассмотреть здесь:

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

Если все это верно, вы можете подумать о подходе к хранилищу свойств like EAV, hstore, json fields, xml fields, etc.

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

Смотрите также: Database design - should I use 30 columns or 1 column with all data in form of 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 (по желанию) отношений к другой таблице. Этот подход может быть полезен, если у вас есть несколько логических группировок атрибутов, которые можно кластеризовать в боковые таблицы.

Я также был бы удивлен, если бы немного больше думал не раскрывать вещи, которые do имеют смысл нормализовать. У вас есть year7_blah, year8_blah, year9_blah и т. Д. Столбцы? Если да: отличный кандидат на нормализацию.

Answer 2

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