Сохраненная процедура или код

Я не прошу мнения, но больше о документациях.Сохраненная процедура или код

У нас есть много файлов данных (XML, CSV, Plantext и т. Д.), И их нужно обрабатывать, данные их несут.

Руководитель базы данных предложил использовать хранимую процедуру для выполнения задачи. В основном у нас есть промежуточная таблица, в которой файл становится сериализованным и сохраняется в столбце clob или XML. Затем оттуда он предложил продолжить использование хранимой процедуры для обработки файла.

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

Итак, мои вопросы: Насколько хорошо работает БД (Oracle, DB2, MySQL, SqlServer), когда мы говорим о поиске регулярных выражений, поиске и замене данных в clob, dom traversal, recursion? По сравнению с языком программирования, таким как Java, PHP или C#, по тем же проблемам.

Редактировать

Так что я ищу, документация по сравнение/выполнения анализа конкретного языка программирования по сравнению с СУБД, в частности, для строки поиска и замены, регулярные выражения поиска и замены. Прохождение XML-сайта. Использование памяти при вызовах рекурсивных методов. И, в частности, насколько они масштабируются при столкновении с 10 - 100 ГБ данных.

источник

2012-04-18 Churk

SP: s подходят для выбора и агрегации. Они легко становятся недостижимыми, когда участвует другая обработка (строка, синтаксический анализ, математика и т. Д.). Является ли производительность действительно проблемой? – adrianm

Обслуживание не является одной из моих проблем, потому что если мы будем следовать пути использования SP, то я не поддерживаю систему, DBA. Но я не хочу стоять без дела, когда вижу, что что-то глупое делается, поэтому только аргумент для меня, который для него верен, я могу сделать это лучше и эффективнее, поскольку переменная обслуживания выходила из моего уравнения. – Churk

«data mining» - очень перегруженный термин. Это может означать что угодно: от вычисления средних до сложных статистических методов $ O (n^3) $ или худшего времени исполнения. Пожалуйста, уточните. Потому что некоторые вещи, очевидно, будут легко выполняться с использованием хранимых процедур. Другие будут больно делать это! –

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

Также следует учитывать ремонтопригодность. Сколько людей в будущем смогут поддерживать решение?

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

источник

2012-04-18 11:27:56

Я понимаю все это. Но мне нужна документация о том, что здравый смысл объяснит. Без какой-либо документации, мой аргумент так же важен, как я считаю, но я не эксперт. Как я уже сказал, я разработчик приложений, и я определенно не верю, что логика вкладывается в уровень хранения. Поэтому я надеюсь, что кто-то из сообщества, возможно, прочитал что-то, что может оправдать то, что я считаю правдой. – Churk

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

Согласно вашему правлению, вы должны сделать это за пределами уровня БД. Вы гораздо более гибкие, особенно в «обход XML-объекта» и «рекурсивные вызовы методов», которые никоим образом не являются частью уровня хранения. Если ваш администратор баз данных будет делать все это, это будет просто доказательством концепции, которая займет много времени и стоит невероятных денег. Я могу просто повторить мне и другие ответы: Уровень хранения не предназначен для этого, это, естественно, будет намного хуже. –

Лучше вывести логику обработки из уровня данных. Профилирование реализации в базе данных будет затруднено.

Вы получаете свободу и возможность выбирать между библиотеками и сравнивать их эффективность, если реализация выполняется на любом языке. Кроме того, вы можете выбрать такие фреймворки, как Spring-Batch для Java, для обработки объемного объема данных в виде пакетного процесса.

источник

2012-04-18 12:03:59

Сохраненная процедура или код

ответ

Смежные вопросы