Вычисления денег, сравнение между Java и Oracle / PL SQL, которые нужно использовать

Question

Ребята, вы можете дать хорошее сравнение относительно Oracle / PL SQL и Java с точки зрения их сильных и слабых сторон при обработке денежных вычислений. Если бы вы разработали приложение, которое будет обрабатывать много денежных вычислений, какое из двух вы бы использовали и почему?

Этот вопрос не для того, чтобы спорить между оракулом / pl sql и java-энтузиастами. Я просто хочу знать, что считается наилучшей практикой или стандартным подходом для такого рода требований и почему.

Сценарий будет:

1. Данные будут взяты из базы данных (минимум Oracle 10g).
2. Программа будет рассчитывать и генерировать счета на основе записей агрегированных данных (100k-1M)
3. Бизнес-правила очень сложны
4. Бизнес-правила могут меняться не реже одного раза в месяц
5. В расчетах будут использованы несколько справочных таблиц
6. Программа будет запускаться один раз в день

Заранее спасибо.

Answer 1

Эти критерии определенно благоприятствуют использованию PL / SQL.

1) Данные будут из базы данных (минимум Oracle 10g).
2) Программа будет рассчитывать и генерировать счета на основе записей агрегированных данных (100k-1M)
5)В расчетах будет использоваться несколько справочных таблиц
6) Программа будет запускаться один раз в день

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

Остальные критерии сложнее оценить:

3) Бизнес-правила очень сложны
4) Бизнес-правила могут меняться как минимум раз в месяц

PL / SQL определенно способен выполнять вычисления и имеет много встроенных арифметических функций.Таким образом, все сводится к тому, что вы подразумеваете под «бизнес-правилами» и «сложными».Мы можем кодировать сложную бизнес-логику в PL / SQL (я это сделал), но в Java есть языковые возможности, которые, несомненно, облегчают задачу: я думаю о таких вещах, как рефлексия и самоанализ.

Возможно, вы думаете об использовании механизма правил?Безусловно, сектор финансовых услуг был основным пользователем Rule Engines.А абстракция наборов правил от обработки облегчит выполнение четвертого критерия.

Java имеет два установленных двигателя правил: Drools и JESS . - это Механизм правил в PL / SQL, и он использовался в течение некоторого времени, но в основном он используется как часть Oracle Streams.Тем не менее, API доступен, поэтому его можно использовать для других целей. Узнайте больше .

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

Answer 2

Я думаю, что наиболее важным аспектом, который вы должны рассмотреть, является "сохранение вашего кода DRY ". Вы должны любой ценой избегать дублирования ваших сложных бизнес-правил на Java и PL / SQL. Сказав это, вы, вероятно, предпочтете поместить большинство из этого в PL / SQL, потому что тогда он будет доступен в процедурах, представлениях и т. Д., Когда он вам действительно понадобится.

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

Answer 3

Вы столкнулись с некоторыми интересными компромиссами здесь.

Сложная, меняющаяся бизнес-логика? Это делает премию за структуру программы. ОО методы, безусловно, применимы. Следовательно, Java кажется подходящим. Серьезная обработка на стороне клиента также может помочь с тестированием и управлением версиями, что также будет важно.

Но вернуть миллион строк для работы? Это будет проблемой производительности.

С дисциплиной вы можете создавать и поддерживать хорошо структурированный PL / SQL. Мое наблюдение состоит в том, что слишком часто люди заканчивают тем, что делали повторное использование методом вырезания и вставки, со временем структура теряется. Я не знаю, каково текущее состояние IDE для PL / SQL, возможно, в наши дни есть инструменты, которые помогут с рефакторингом. Конечно, в мире Java инструменты рефакторинга довольно хороши, поэтому барьер для сохранения хорошей структуры низок.

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