Jan: 2017-02-28 22:36 GMT+01:00 Jan Lessner <[email protected]>:
> > - Unit-Testability of the code > - Reuse of existing Java code modules > - Complicated business logic on the way from source records to > destination records > - Different databases in development and production > - Missing knowhow to maintain PL/SQL > > Interesting. Well, I don't have all the bits of information, and there might be huge pain hiding in bullet number 3, but I think you might be burning some money on Exadata there if you don't use PL/SQL :) Here's some interesting (biased of course) insight: https://www.youtube.com/watch?v=odf_jxK7lDA I do recommend you reconsider, and at least benchmark your solution against an alternative with more data processing logic in the database. I contract for a client that loads and unloads several millions of rows into dozens of tables per night in Oracle through Perl and PL/SQL, similar order of magnitude as what you're talking about. They also run their more complex business logic in Java processes that get triggered using Oracle AQ from within the database. I don't have numbers about messages per second, but their Oracle instance certainly doesn't squeal yet. Oracle AQ is really completely underrated! Heck, I'd even recommend not just using PL/SQL but SQL only using Oracle's multi-table INSERT extension for your specific insertion use-case: http://allthingsoracle.com/multi-table-insert-statements-in-oracle/ But anyway, you have your reasons. So, essentially you're looking for jOOQ native support for precisely that multi-table INSERT statement (which would then also work in other DBs). Unfortunately, it doesn't exist yet, but it's certainly a good idea to support. Multi table streams could be "bulked", batched, and committed in a quite nice manner using the Loader API (or an extension thereof). We'd need a set of source to target mapping functions that transform the input data into different streams of output data. I've created a feature request for this: https://github.com/jOOQ/jOOQ/issues/5930 > just to name a few. Taking the mentioned real-world usecase as an example: > In this case the exact content of the history entries are assembled from a > dynamic Excel template using the openL rule engine. This is Java > technologie without an alternative in PL/SQL. > Oh, there's a jOOQ user out there who would put that library into the database and run a JVM inside of Oracle :) But that might not be a very good idea... Cheers, Lukas -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
