Database independence is not just different databases. It is having a
logical view of the data that is different from the physical view.

In the following, as far as the program that is using it is concerned
the database looks like a single integer.

// Check to determine if fleet is active for this truck and has not been
//   processed previously.
Exec Sql Select Count(*)
           Into :Count
           From UNITS t1
             Inner Join TRANSFER_CONTROL t2
               On t1.UNDFLT = t2.FLEET
             Exception Join UNITS_TRANSFERRED t3
               On t1.UNUNIT = t3.UNIT_CODE
           Where t1.UNUNIT = :InTruckCode And
                 CURRENT TIMESTAMP Between
                   t2.START_DATETIME And t2.END_DATETIME;

Alternatively in RPG using file I/O I am chaining in the UNITS table
to get the fleet, chaining to the TRANSFER_CONTROL to see if the fleet
is present and then checking the record to see if the dates are active
and then chaining to the UNITS_TRANSFERRED to see if the unit has
already been transferred. Whew. But the important thing is that I now
have three different tables that the full table is complied into my
program and my database is locked. I now want to add a single field to
UNITS but UNITS is used in 1500 programs.

People always say oh we can just recompile the programs. The only
problem is in 35 years I have never seen anybody do it. It is take
another field and make something it is not, create an extension table,
do maturations in the code that would make you puke or the ever
present favorite hard coding some value into the program to just to
avoid having to do that.

Contrast that with using SQL or externallizing the I/O. With SQL you
change the table and you done. With externallizing, you recompile the
one program. As in the examples above that still gives you a lot of
complexity vs simply writing a single SQL statement.

If you watch development in a Java or .Net or some other SQL based
environment you watch the databases being changed constantly as new
information is added. In RPG once those suckers are created, nobody
wants to change anything. Development is completely different.

As to the overhead, when you use framework you define objects and
objects encapsulate multiple tables like a customer. You want the
customer's address but internally the framework goes out and chains in
maybe a half a dozen or more tables and puts them in memory. There are
strategies for trying to reduce this but it still adds all kinds of
overhead. This is even true in RPG. Try taking a physical file and
defining a field select logical on it to bring in only what you want
and then do any form of sequenctial I/O. You will be amazed how much
faster it will be than reading the entire record in and, of course, as
you see in the above example the only thing being returned from the
database is an integer count. In contrast with record I/O I have read
in three different tables and all the data in them.

My main point being that IBM and other vendors have spent 100's of
millions of dollars making SQL the best I/O they can. Why not use it,
free your database and put most of the business logic in the database.




On Wed, Apr 4, 2012 at 11:48 AM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:

Regarding:
'I agree with everything you are saying except "Why try to achieve database independence". Huh!!'

I assume the guys was talking about different databases like MS SQL, Oracle, MySQL, DB2, etc.

--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.


This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].