Плюсы и минусы массивной таблицы, которая контролирует весь поток данных с помощью хранимых процедур

Question

Администратор баз данных (всего 2 года обучения Google) создал массивную таблицу управления данными (108 столбцов и больше), содержащую все необходимые атрибуты для любого потока данных в системе. Ну, кратко, назовите этот стол BFT.

из этих столбцов:
10 для метаданных.
15 для источника данных и временного отслеживания
1 экземпляр столбцов new / curr для текстовых данных
10 экземпляров новых / текущих / дельта / коэффициент / столбцы диапазона для многозначных числовых обновлений : всего 50 столбцов.

Для многозначных числовых обновлений обычно требуется только 2-5 групп обновлений.

Пакеты записей 15K-1500K загружаются в BFT и обрабатываются хранимыми процессами с логикой, чтобы проверить эти записи, перетаскивая их на постоянное хранение примерно в 30 других таблицах.

В большинстве загрузок записей 50-70 столбцов пусты в течение всего процесса.

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

Учитывая это очень маленькое понимание модели обработки данных, у кого-нибудь есть мысли или предложения? Можно ли доверять базе данных (SQL Server) для эффективной обработки записей с в основном пустыми столбцами, или обработка таким образом приводит к потере большого количества циклов / памяти и т. Д.

Answer 1

Похоже, он заново изобрел BizTalk .

Answer 2

Одной вещью, которая может сделать вещи немного более гибкими (кроме нормализации), может быть создание одного или нескольких представлений или табличных функций для представления данных. В частности, если таблица находится вне вашего контроля, это позволит вам отфильтровать ложное дерьмо и извлечь из таблицы только то, что вам нужно.

Однако, если вы собираетесь стать одним из тех, кто будет работать (и хмурится каждый раз, когда вам придется взламывать) эту огромную таблицу, вам, возможно, захочется превзойти «дизайн» АБД и нормализовать этого зверя. и, возможно, поручить администратору БД создать некоторые представления и / или табличные функции, чтобы помочь you out.

В настоящее время я работаю с похожей, но не такой огромной таблицей, которая уже много лет используется в нашей системе и в которой есть новые поля, индексы и ограничения, довольно поспешно связанные с франкенштейновским стилем. К сожалению, некоторые другие рабочие группы полагаются на структуру как на евангелие, поэтому мы создали такие представления и функции, которые позволяют нам «формировать» данные так, как нам нужно.

Answer 3

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

Что касается пустых столбцов, если на них нет ссылок в конкретном запросе, обрабатывающем BFT, это не имеет значения - ОДНАКО, что произойдет, если индексация станет гораздо более важной, чем выбранный индекс некластерный покрывающий индекс. Когда используется ваш BFT и выбрано сканирование таблицы или сканирования кластерного индекса, неиспользуемый столбец необходимо прочитать и игнорировать или пропустить, и это определенно влияет на обработку в моем опыте. В то время как при сканировании или поиске некластеризованного индекса читается меньше столбцов, и, надеюсь, это не включает (m) ни одного из неиспользуемых столбцов.

Answer 4

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