Управление большими объемами данных - хранимые процедуры или наборы данных или другие ...?

Question

У меня есть приложение, которое ежедневно импортирует большие объемы данных, несколько сотен тысяч записей.
Данные поступают из разных источников. Данные читаются с использованием C #, а затем массово вставляются в базу данных.

Эти данные затем обрабатываются:

• связаны разные таблицы
• создаются новые таблицы
• данные корректируются с использованием сложных алгоритмов (итоги некоторых таблиц должны равняться нулю)

Большая часть этой обработки выполняется в хранимых процедурах.
Хотя некоторая сложная обработка была бы проще в C #, извлечение данных в набор данных и их повторное внедрение значительно замедлило бы процесс.
Вы можете спросить, почему я не обрабатываю данные перед их вставкой в ​​базу данных, но я не считаю целесообразным манипулировать 100 000 записей в памяти, а команды на основе набора SQL помогают при создании большого количества записей.

Это, вероятно, поднимет вековой вопрос использования хранимых процедур и их плюсы и минусы. (например. Как вы тестируете хранимые процедуры?)

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

Answer 1

Обычно мне приходится соглашаться со Skliwz, когда дело касается MSSQL. SSIS и DTS - это путь, но если вы не знакомы с этими технологиями, с ними может быть сложно работать. Однако есть альтернатива, которая позволит вам выполнять обработку в C # и сохранять ваши данные внутри SQL Server.

Если вы действительно думаете, что обработка в C # будет проще, вам может потребоваться использовать SQL Server Project для создания объектов базы данных с использованием C # . Есть много действительно мощных вещей, которые вы можете сделать с объектами CLR внутри SQL Server, и это позволит вам писать и тестировать код до того, как он коснется базы данных. Вы можете модульно протестировать свой код CLR внутри VS, используя любую из стандартных платформ модульного тестирования (NUnit, MSTest), и вам не нужно писать кучу сценариев установки и демонтажа, которыми трудно управлять.

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

Answer 2

Я бы использовал SSIS или DTS (если вы говорите о MSSQL). Они сделаны для этой цели и работают с ИП, если они вам нужны.

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

Относительно "Как вы выполняете процедуры хранения модульного теста", вы тестируете их модулем MBUnit, как и все остальное. Только небольшой совет: установка и откат данных могут быть сложными, вы можете использовать транзакцию DTS или явные операторы SQL.

Answer 3

Способ обработки данных в значительной степени зависит от того, что вы делаете. Если вам нужно, например, отбросить данные, которые вам не нужны, в вашей базе данных, то вы обработаете их в своем коде C #. Однако данные для обработки в базе данных, как правило, должны быть данными, которые не должны зависеть от реализации. Поэтому, если кто-то еще хочет вставить данные из клиента Java, база данных должна быть в состоянии отклонить неверные данные. Если вы поместите эту логику в свой код C #, код Java об этом не узнает.

Некоторые люди возражают и говорят "но я никогда не буду использовать другой язык для базы данных!" Даже если это правда, у вас все еще есть администраторы баз данных или разработчики, работающие с базой данных, и они сделают ошибки, если логика отсутствует. Или ваш новый разработчик C # попытается добавить данные и не знать (или просто игнорировать) препроцессоры данных, написанные на C #.

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