Re: Database I/O Modernization

The problem with benchmarks is it is pretty much apples and oranges.

If you do a single file chaining out and compare to a single SQL statement
doing the same thing, I am sure RLA will be faster if for no other reason,
RLA is wired directly into record I/O service program and SQL has to make a
program call.

The problem is that you don't use SQL like you use RLA. In RLA, you read a
record, compare a value and read another table and check a value and read
another table.

In SQL you are probably to read all three tables and select the records
only if tests are meet. In other words, you have an access plan.

The thing to recognize is if you design your database correctly, the
database engine does all the work. Code start disappearing. You cannot do
that with RLA.

The only reason that I can see to externalize I/O is to provide database
independence. The single most serious problem with RLA is that it brings
the entire table into your program. The logical view of the data and the
physical view is the same.

Anyone who has been in this business very long knows what happens when you
get a table used all over the place. No one wants to change it Pretty soon
extension tables and then extension of extensions start sprouting up.
Databases are dynamic. Changing all the time. RLA looks in the physical
view of the data.

Of course, if you are using SQL correctly that is exactly what it lets you
do. Have a logical view of the database that is different than the physical
view.


On Fri, Sep 15, 2017 at 1:44 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

The real proof is in benchmarks. And I don't have time to go through them
one by one. But I should respond to your assertions.

On Fri, Sep 15, 2017 at 1:50 PM, Charles Wilt <charles.wilt@xxxxxxxxx>
wrote:

Nathan,

Pretty much completely wrong...

You appear to have a habit of bluntness. Sometimes it works for your
benefit. But this is not one of those times.

Originally, SQL & RLA did use the same interface to the DB ...

That's an ambiguous statement. I don't believe that any SQL engine on IBM i
has ever bound to the QRNXIO service program that RPG programs bind to, nor
invoked the procedures that correspond with the op codes (open, close,
read, write, chain, etc.).

that's what's
known now as the Class Query Engine (CQE).

Again, I would challenge that the CQE ever used "the same interface to the
DB..."

You've evidently read about IBM rewriting its query engine and giving it a
new name, but you lack knowledge about its internals. Don't take that as a
put down. IBM hasn't revealed a lot of details.

But SQE was completely new, lots of stuff was added below the MI to handle

SQL operations; taking advantage of the tight integration between DB &

OS.

There are some good documents out there about the SQE that make it obvious
that the new engine is using RLA under the covers.

As mere mortals working above the OS, we can't take advantage of any of

it

with RLA.

This is where your ignorance begins to show. I don't have a good reference
to point to at the moment, but IBM has indicated that DB improvements at
the MI level show up in RLA interfaces too.

End result, SQL is faster and will continue to get faster than RPG RLA.

That contradicts what I've read. Do you have a source?
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD