Re: Working with tables, best method

If I am developing new code, I use almost 100% SQL. For maintenance, I
may not have a choice.

One thing that gets forgotten most of the time in this argument about
file I/O vs. using SQL is database independence.

To me, this is reason enough to use SQL. Every time I use File I/O, I am
hardwiring the format of the table to the program. Need to change the
table and everything has to be recompiled.

If you were to sit down and figure out the cost of not having database
independence over the years to AS/400 shops, the numbers would be
staggering.

On any other system, if I need a new field, I just add it.

In addition, with file I/O, you are bringing in the entire table. With
SQL, you are bringing in only what you need.

I, also, think in normal usage of SQL the speed question gets to be
mute.

Very rarely do you create an SQL statement that use a single table or,
at least, I don't. I am almost always going to write an SQL statement
that reads several files.

The other issue for me is readability. I can look at one SQL statement
and see the I/O laid out. I can pull that SQL out of the program and run
it if I am not clear on what is does.

Try sitting down and figuring out what is going on with File I/O. Chain
here, read there, chain here, read there, chain there, chain here.
Trying to figure out what is going on can be an absolute nightmare.

I don't think the question should be if, it should be only use File I/O
if you must. SQL is the present and the future and the language of every
other system out there.

If you are going to do any work on any other system, you are going to be
doing SQL.

I think my biggest gripe with SQL is that IBM has not implemented SQL as
service program. File I/O is done using service programs but we still
are using program calls to execute SQL from RPG programs. The SQL
precompiler should be rewritten for ILE a long time ago but has never
been done.