Глупо ли писать большую программу пакетной обработки полностью на PL / SQL?

Question

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

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

Это плохая идея делать все это в PL / SQL? Вы бы предпочли выполнять тяжелые пакетные вычисления на типичном объектно-ориентированном языке программирования, таком как C #? Разве не более выразительно использовать язык программирования, ориентированный на базу данных, такой как PL / SQL?

Answer 1

Вы описываете следующие требования

а) Должен быть в состоянии реализовать пакетную обработку б) Результат должен быть поддерживаемым

Мой ответ:

1. PL / SQL был разработан для достижения именно того, что вы описываете. Также важно отметить, что в PL / SQL есть преимущества, которых нет в других инструментах. Язык хранимых процедур помещает обработку рядом с данными - именно там должна располагаться пакетная обработка.
2. Достаточно легко написать плохо обслуживаемый код на любом языке.

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

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

Можно успешно использовать оба подхода.

Мэтью Батлер

Answer 2

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

Answer 3

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

Oracle разработала PL / SQL с учетом подобных проблем, если у вас есть достаточные корпоративные знания о базе данных и PL / SQL, это кажется разумным решением. Помните о больших пакетных наборах, так как каждый вызов PL / SQL к фактическому механизму SQL является переключением контекста, поэтому процессы с одной записью должны объединяться вместе, где это возможно, для повышения производительности.

Answer 4

PL / SQL - это зрелый язык, который хорошо интегрируется с SQL. С каждой версией Oracle она становится все более и более мощной. Также начиная с Oracle 11, PL / SQL по умолчанию компилируется в машинный код.

Answer 5

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

Answer 6

Я написал огромное количество программ для пакетной обработки и генерации отчетов на PL / SQL и Pro C для одного проекта. Как правило, они предпочитали, чтобы я писал на PL / SQL, поскольку их собственные разработчики, которые будут поддерживать в будущем, найдут это проще для понимания, чем код Pro C.

В конечном итоге это была просто очень интересная обработка или отчеты, написанные на Pro * C.

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

Answer 7

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

Однако, поскольку это пакетная обработка, а вход и выход являются БД, имеет смысл поместить логику в PL / SQL, чтобы минимизировать «движущиеся части». Однако, если бы это была бизнес-логика - или компоненты, используемые другими частями вашей системы - я бы сказал, не делайте этого.

Answer 8

Я создал пакетные программы с использованием C # и SQL.

Плюсы C #:

У вас есть полная библиотека .NET и все возможности языка OO.

Минусы C #:

* Пакетная программа и отдельная БД - это означает, что вам придется управлять своей пакетной программой отдельно от базы данных.

* Вам нужно убежать от всего этого чёртового кода.

Плюсы SQL:

* Прекрасно интегрируется с СУБД. Если эта работа манипулирует только базой данных, имеет смысл включить ее в базу данных. В итоге вы получите один БД и все его компоненты в одном пакете.

* Нет необходимости экранировать sql код

* поддерживая реальность - вы программируете в своей проблемной области

Минусы SQL:

Это SQL, и я лично не знаю его так же хорошо, как SQL.

В общем, я бы придерживался использования SQL из-за плюсов, описанных выше.

Answer 9

Поскольку вычисления, которые вам необходимо выполнить, могут быть адекватно и легко читаемы в PL / SQL, тогда использование только PL / SQL будет наиболее целесообразным.

Реальный подвох - это удобство сопровождения - очень просто написать неуправляемый SQL, хотя бы потому, что каждая СУБД имеет свой синтаксис и разные функции, установленные после выхода из простого SQL DML, и отсутствия реальных стандартов форматирования. комментирование и т. д.

Answer 10

Это загруженный вопрос :) Вам нужно знать несколько архитектур архитектуры баз данных и их преимущества / затраты. 2 Уровень обычно означает, что у вас есть клиент, подключающийся к БД и выполняющий прямые вызовы SQL. 3 Уровень обычно означает, что у вас есть «сервер приложений», который отправляет прямые вызовы SQL в БД, но клиент общается с сервером приложений. Как правило, это позволяет «масштабировать». Наконец, у вас есть 2 1/2 многоуровневых приложения, которые используют двухуровневый формат, только работа распределена внутри хранимых процедур.

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

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

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

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

ГММВ:)