金钱计算，java 和 Oracle/PL SQL 的使用比较
大家可以对 Oracle/PL SQL 和 Java 在处理货币计算时的优缺点进行很好的比较。 如果您要开发一个需要处理大量资金计算的应用程序，您会使用这两者中的哪一个？为什么？
这个问题并不是要引发oracle/pl sql和java爱好者之间的争论，我只是想知道这种需求的最佳实践或标准方法是什么以及背后的原因。
场景是：
- 数据来自数据库（最低 Oracle 10g）。
- 该程序将根据聚合数据（100k-1M）记录计算并生成发票
- 业务规则非常复杂
- 业务规则可能每月至少更改一次
- 计算中将使用多个参考表 程序
- 将每天运行一次
提前致谢。
Guys can you give a good comparison regarding Oracle/PL SQL and Java in terms of their strengths and weaknesses when handling monetary computations.
If you were to develop an application which will be handling a lot of money computations which of the two would you use and why?
This question is not to spark a debate between oracle/pl sql and java enthusiasts I just want to know what is considered the best practice or standard approach for this kind of requirement and the reason behind.
Scenario would be:
- Data would be from the database (Oracle 10g minimum).
- The program would compute and generate invoices based on aggregated data (100k-1M) records
- Business rules are very complex
- Business rules may change at least once a month
- Several reference tables will be used in the computation
- Program will be ran once a day
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这些标准绝对有利于 PL/SQL 的使用。
如果程序在数据库中并且涉及数据，特别是大量数据，那么PL/SQL是默认选项。
其余的标准很难评估：
PL/SQL 绝对有能力进行计算，并且它有很多内置的算术函数。因此，这归结为“业务规则”和“复杂”的确切含义。我们可以用 PL/SQL 编写复杂的业务逻辑（我已经做到了），但 Java 的语言特性无疑使任务变得更容易：我正在考虑诸如反射和内省之类的东西。
也许您正在考虑使用规则引擎？当然，金融服务业一直是规则引擎的主要用户。从处理中抽象出规则集将更容易满足第四个标准。
Java 有两个已建立的规则引擎，Drools 和 JESS。 PL/SQL 中有一个规则引擎，并且已经存在了一段时间，但它主要用作 Oracle Streams 的一部分。然而，API 是公开的，因此可以用于其他目的。 了解更多信息。
如果您正在考虑规则引擎，那么我认为这会向 Java 倾斜。业务规则处理是一种专业的编程范例，Java 比 PL/SQL 对此有更多的经验和支持。我怀疑这意味着在中间层使用 Java 而不是 Java 存储过程，这会对网络流量和性能产生影响。
These criteria definitely favour the use of PL/SQL.
If it's in the database and involves data, especially lots of data, then PL/SQL is the default option.
The remaining criteria are trickier to evaluate:
PL/SQL is definitely capable of undertaking computation, and it has lots of built-in arithmetic functions. So it comes down to exactly what you mean by "business rules" and "complex". We can code complex business logic in PL/SQL (I have done it) but Java has language features which undoubtedly make the task easier: I'm thinking of stuff like reflection and introspection.
Perhaps you are thinking about using a Rule Engine? Certainly, the financial services sector has been a major user of Rule Engines. And abstracting the rule sets from the processing would make it easier to satisfy the fourth criterion.
Java has two established Rule Engines, Drools and JESS. There is a Rule Engine in PL/SQL, and has been for some time, but it is mainly used as part of Oracle Streams. However, the API is exposed so it could be used for other purposes. Find out more.
If you're thinking about Rule Engines then I think that tips the hand towards Java. Business Rules Processing is a specialist programming paradigm, and there is simply more experience and support for it in Java than PL/SQL. I suspect that means going for Java in the middle tier rather than Java Stored Procedures, which has implications for network traffic and performance.
我认为您应该考虑的最重要的方面是“保持代码干燥 ”。您应该不惜一切代价避免将复杂的业务规则复制到 Java和 PL/SQL。话虽如此，您可能更喜欢将其大部分放入 PL/SQL 中，因为这样当您真正需要它时，它就可以在过程、视图等中使用。
无论如何，出于性能原因，考虑到应用于中等数据量的任务的复杂性，您可能会在数据库中执行“数据聚合”。因此，如果您确实需要聚合业务规则，它们已经在数据库中可用。无需往返 Java。
I think the most important aspect you should consider is "keeping your code DRY". You should at all costs avoid duplicating your complex business rules to both Java and PL/SQL. Having said this, you are likely to prefer putting most of it in PL/SQL, because then it will be available in procedures, views, etc when you actually need it.
In any case, for performance reasons, you are probably going to perform "data aggregation" in the database considering the complexity of tasks applied to a medium-sized amount of data. So if you actually need business rules for aggregation, they're already available in the database. No round-trip to Java is needed.
您在这里面临一些有趣的权衡。
复杂、多变的业务逻辑？这对程序结构非常重要。面向对象技术肯定是适用的。因此 Java 似乎很适合。在客户端进行认真的处理也可能有助于测试和版本控制，这也很重要。
但是，带回一百万行来处理吗？这将是一个性能挑战。
通过遵守纪律，您可以生成和维护结构良好的 PL/SQL。我的观察是，人们常常通过剪切和粘贴来进行重用，随着时间的推移，结构就会丢失。我不知道 PL/SQL 的 IDE 目前状况如何，也许现在有工具可以帮助重构。可以肯定的是，在 Java 世界中，重构工具非常好，因此保持良好结构的障碍很低。
我的理想场景是，跨百万行的某些查询集将产生需要复杂修改的小数据集，我们可以在 Java 中进行修改。因此，用 SQL 获取数据，用 Java 处理数据——两者都达到了最佳点，而无需付出过多的数据传输性能损失。我们对您的要求了解不够，不知道这是否可行。
You are facing some interesting trade-offs here.
Complex, changing, business logic? That places a premium on program structure. OO techniques are surely applicable. Hence Java seems a good fit. Doing serious processing client side may also help with testing and versioning which will also be important.
But, bringing back a million rows to work on? That's going to be a performance challenge.
With discipline you can produce and maintain well-structured PL/SQL. My observation is that all too often folks end up doing reuse by cut-and-paste, over time structure is lost. I don't know what the current state of IDEs for PL/SQL, maybe these days there are tools to help with refactoring. For sure in the Java world the refactoring tools are pretty good, so the barrier to keeping good structure is low.
My ideal scenario would be that some set of queries across the million rows would result in small sets of data that need complex munging, and we can do that munging in Java. So SQL for getting the data, Java for processing it - hit the sweet spot for both without paying excessive data transfer performance penalties. We don't know enough about your requirements to know if that's possible.