Проектирование БД и извлечение данных из тяжелой таблицы

У меня есть требование иметь 612 столбцов в моей таблице базы данных. Количество столбцов в соответствии с типом данных:

BigInt — 150 (PositionCol1, PositionCol2…………PositionCol150)

Инт - 5

Маленькое целое – 5

Дата — 150 (SourceDateCol1, SourceDate2,………….SourceDate150)

ДатаВремя – 2

Varchar(2000) – 150 (FormulaCol1, FormulaCol2………………FormulaCol150)

Бит — 150 (IsActive1, IsActive2,……………….IsActive150)

Когда пользователь выполняет импорт в первый раз, данные сохраняются в PositionCol1, SourceDateCol1, FormulaCol1, IsActiveCol1 и т. д. (другие столбцы datetime, Int, Smallint).

Когда пользователь выполняет импорт во второй раз, данные сохраняются в PositionCol2, SourceDateCol2, FormulaCol2, IsActiveCol2 и т. д. (другие столбцы datetime, Int, Smallint)… .. и т. д.

В таблице есть столбец ProjectID, для которого импортируются данные.

Перед началом процесса импорта пользователь сопоставляет имена столбцов Excel с именами столбцов базы данных (PositionCol1, SourceDateCol1, FormulaCol1, IsActiveCol1), и это сопоставление сохраняется в отдельной таблице; чтобы при извлечении данных можно было отображать эти имена столбцов сопоставления вместо имен столбцов БД. Например.

PositionCol1 может быть сопоставлен с SAPDATA

SourceDateCol1 может быть сопоставлен с SAPDATE

FormulaCol1 может быть сопоставлен с SAPFORMULA

IsActiveCol1 может быть сопоставлен с SAPISACTIVE

40 000 строк будут добавляться в эту таблицу каждый день, мой вопрос заключается в том, сможет ли SQL обрабатывать такое количество данных в долгосрочной перспективе?

В большинстве случаев строка будет содержать данные примерно в 200-300 столбцах; в худшем случае у него будут данные во всех 612 столбцах. Имея это в виду, должен ли я внести некоторые изменения в дизайн, чтобы избежать проблем с производительностью в будущем? Если да, то подскажите, что можно сделать?

Если я буду придерживаться своего текущего дизайна, о каких моментах я должен позаботиться, помимо индексации, чтобы иметь оптимальную производительность при извлечении данных из этой огромной таблицы?

Если мне нужно получить данные определенного объекта, например. SAPDATA, мне нужно перейти к моей таблице сопоставления, получить имя столбца базы данных по SAPDATA, т. е. в данном случае PositionCol1; и получить его. Но таким образом мне придется писать динамические запросы. Есть ли другой лучший способ?


person user899055    schedule 01.06.2012    source источник


Ответы (1)


Не придерживайтесь вашего текущего дизайна. Ваши повторяющиеся группы громоздки и самоограничены... Что происходит, когда кто-то загружает 151 раз? Нормализуйте эту таблицу так, чтобы у вас было по одному типу каждого типа в строке, а не 150. Вам не понадобится сопоставление таким образом, поскольку вы можете выбрать SAPDATA из positioncol, не беспокоясь, если это 1-150.

Вероятно, вам нужна таблица PROJECTS с идентификатором, таблица PROJECT_UPLOADS с идентификатором и FK для таблицы PROJECTS. Эта таблица будет иметь Position, SourceDate, Formula и IsActive, учитывая ваш вариант использования выше.

Тогда вы могли бы делать такие вещи, как

выберите p.name, pu.position из PROJECTS p внутреннее соединение PROJECT_UPLOADS pu on pu.projectid = p.id WHERE pu.position = 'SAPDATA'

и Т. Д.

person Jeff Watkins    schedule 01.06.2012
comment
Я уже обжегся на предложенном дизайне, так как строки должны сводиться в столбцы для ряда столбцов с помощью динамических запросов. Итак, если у вас много данных, этот дизайн не работает. - person user899055; 01.06.2012
comment
А столбцы фиксированные и увеличиваться не собираются. Кроме того, поскольку данные хранятся так же, как я хочу получить, поэтому поиск данных происходит довольно быстро, потому что ему не нужно выполнять поворот. - person user899055; 01.06.2012
comment
Когда вы говорите, что 40 000 строк в день, сколько из них будет активным? Это исторические данные? Вы можете секционировать данные в большинстве современных СУБД, что сведет к минимуму влияние на производительность (в зависимости от того, как структурированы ваши запросы). Возможно, вы захотите рассмотреть решение для хранения данных, так как а) оно поможет вам с предлагаемой вами структурой (т. е. сделает ваши запросы простыми и быстрыми) и б) снизит нагрузку на работающую систему. Но я недостаточно хорошо понимаю ваш вариант использования, чтобы дать твердую рекомендацию. - person Jeff Watkins; 01.06.2012
comment
Может ли кто-нибудь предоставить некоторые предложения/комментарии? - person user899055; 01.06.2012
comment
Точно, Джефф. Вот о чем я думаю. а) Сделать запросы простыми и быстрыми с текущим дизайном, а затем уменьшить нагрузку на действующую систему, взяв исторические таблицы. Мне нужно было подтверждение от экспертов. Можете ли вы сказать, что вы не поняли из данного варианта использования? - person user899055; 01.06.2012
comment
Сколько строк является текущими, то есть можете ли вы архивировать каждые x часов/дней/недель. Ваша отчетность предназначена в основном для исторических целей или это должны быть 100% живые данные? Как он вставляется/обновляется в действующую базу данных? - person Jeff Watkins; 01.06.2012
comment
Все 40000 строк будут актуальными изначально, и данные в этой таблице можно архивировать каждые 4 недели. Данные будут вставлены с помощью импорта Excel, а также с помощью ручного ввода. Дайте мне знать, если это поможет. - person user899055; 01.06.2012
comment
Может ли кто-нибудь предоставить предложения/комментарии по этому поводу? - person user899055; 01.06.2012
comment
Это выходит за рамки возможности обсуждать в небольших полях для комментариев. Не стесняйтесь пригласить меня поговорить об этом. - person Jeff Watkins; 02.06.2012
comment
Как я могу пригласить вас в чат? - person user899055; 02.06.2012