Комплексная обработка в хранимых процедурах против приложения .net

Question

Мы создаем новое приложение в .net 3.5 с базой данных SQL-сервера. База данных довольно большая, около 60 таблиц с данными. Приложение .net имеет функцию для переноса данных в эту базу данных из ввода данных и из сторонних систем.

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

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

Например, мне нужно запросить одну таблицу, которая вернет мне 2000 строк, тогда для каждой строки мне нужно запросить другую таблицу, которая вернет мне 300 результатов, чем для каждой строки этого мне нужно запросить несколько таблиц (около 10) чтобы получить необходимые данные, сделайте расчет и сохраните результат в другой таблице.

Теперь мой вопрос, я должен продолжить с решением хранимых процедур и забыть о независимости базы данных, так как производительность важна. Я также думаю, что время разработки будет намного меньше, если мы будем использовать решение хранимых процедур. Если кто-то из клиентов хочет получить это решение, скажем, в базе данных oracle (потому что он не хочет поддерживать другую базу данных), то мы портируем хранимые процедуры в базу данных oracle и поддерживаем две версии для любых будущих изменений / улучшений. Аналогичным образом другие клиенты могут запрашивать другие базы данных.

---

2000 строк, о которых я упоминал выше, относятся к продукту skus. 300 строк, которые я упомянул, имеют различные атрибуты, которые мы хотим вычислить, например, стоимость обработки, транспортные расходы и т. д. В 10 упомянутых мной таблицах содержится информация о конвертации валюты, конвертации единиц, сети, области, компании, цене продажи, количестве проданных за день и т. д. В итоговой таблице вся информация хранится в виде звездообразной схемы цель анализа и отчетности. Цель состоит в том, чтобы в любой момент получить информацию о продукте, чтобы каждый знал, какой атрибут продажи продукта стоит нам денег и где мы можем сделать улучшение.

Answer 1

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

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

Вы говорите:

Мне нужно запросить одну таблицу, которая будет верните мне 2000 строк, то для каждой строки Мне нужно запросить другую таблицу, которая вернет мне 300 результатов, чем для каждая строка этого мне нужно запросить несколько столов (около 10), чтобы получить необходимые данные

из вашего вопроса похоже, что вы не используете объединения, и вы уже мыслите циклично. даже если вы намереваетесь выполнить цикл, гораздо лучше написать запрос для объединения всех необходимых данных, а затем выполнить цикл по нему. помните, что операторы update и insert могут иметь чрезвычайно сложные запросы. включите в операторы CASE, производные таблицы, условные объединения (LEFT OUTER JOIN), и вы сможете практически решить любую проблему за одно обновление / вставку.

Answer 2

Что ж, без каких-либо конкретных подробностей о том, какие данные у вас есть в этих таблицах, лишь обратная сторона расчета салфетки показывает, что вы говорите об обработке более 6 миллионов строк информации в представленном вами примере (2000 строк * 300 строк * (1 строка * 10 таблиц)).

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

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

Answer 3

Хранимые процедуры каждый раз, но, как сказал КМ в этих хранимых процедурах, сводят эти итерации к минимуму, то есть используют соединения в вашем SQL, реляционные базы данных оооочень хорошо объединяются.

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

Независимость от базы данных на самом деле не существует, за исключением самых тривиальных приложений CRUD, поэтому, если ваше первоначальное требование состоит в том, чтобы все это работало с SQL Server, то используйте инструменты, которые предоставляет СУБД (в конце концов, ваш клиент потратил много дело денег на нем). Если (и это очень важно, если) последующий клиент действительно не хочет использовать SQL Server, тогда вам придется кусать пулю и кодировать ее в другом варианте хранимой процедуры. Но потом, как вы определили, «если я все это время делаю в .net по базе данных запросов, я не думаю, что она сможет быстро закончить работу». вы покрыли расходы на это до тех пор, пока и когда это потребуется.

Answer 4

Программирование таких вещей, как расчетный код, как правило, проще и удобнее в C #. Кроме того, нормальным является поддержание минимальной обработки на SQL Server, поскольку базу данных труднее всего масштабировать.

Сказав, что из вашего описания звучит так, что подход хранимых процедур - это путь. Когда код расчета зависит от больших объемов данных, перенос данных с сервера для расчета будет более затратным. Таким образом, если у вас нет разумных способов оптимизации зависимых данных (таких как кэширование справочных таблиц?), То вы, скорее всего, найдете это более болезненным, чем использование хранимого процесса.

Answer 5

Я хотел бы рассмотреть возможность сделать это в службах интеграции SQL Server (SSIS). Я поместил бы вычисления в SSIS, но оставил бы запросы как хранимые процедуры. Это обеспечит вам независимость от базы данных - SSIS может обрабатывать данные из любой базы данных с подключением ODBC, а также высокую производительность. Только простые операторы SELECT будут присутствовать в хранимых процедурах, и они являются частями стандарта SQL, которые, скорее всего, будут идентичны для нескольких продуктов баз данных (при условии, что вы придерживаетесь стандартных форм запросов).