RLA & SQL was (Re: SQL database object names longer than 10 characters and mixedcase?)

OK Dieter, I'll bite :-).

I have changed the title - I think this has wandered far from the original post.

I think you need to go back and read Joe's e-mail again - it does have some valid points.

Just to remove some of the flack from this discussion - no one is advocating the use of DDS over DDL. So let's remove that from the table (pun unintended) - we are discussing the use of RLA and whether or not it has a place in a modern application.

I would say yes. It is not a case of all SQL or all RLA but a case of both - whichever makes most sense. If I am doing something where a transaction spreads multiple tables (or multiple rows on the same table), I will use SQL. If I am doing something where I need just one row (e.g. get a description or a name), I will use RLA - but not by coding an F spec in the program.

The proper use of RLA (as opposed to the traditional use of RLA) means that the RLA should be encapsulated. Therefore, if the underlying data changes, then only one module in the whole application needs to be re-compiled. It all comes down to the design.

I don't like being in the position where my application will be "a little bit slower, or needs a little bit more hardware ressources" just because of a programming style decision. And when there is little or no difference between RLA and SQL access speeds for a single row being returned, I will gladly drop RLA.

Your description of commitment control is all true - but it is smoke :-) You can meet all the commitment control requirements with RLA - it is just a bit more work.

I wonder if you could expand on a couple of points Dieter?

You said "Using two concurrent technologies to do the same, (DDS and DDL, or SQL and RLA) complicates application developments and the readability of code is worse, then concentrating on one of the technologies, so there is a decision to make between SQL and the native interfaces". I'm sorry, I really don't see how the readability of code is worse.

You said "RLA transfers binary huddle between the database and the application with higher risc of data corruption." How?

Regards

Paul Tuohy
ComCon
www.comconadvisor.com www.systemideveloper.com




dieter.bender@xxxxxxxxxxxx wrote:

thats a flame? its hot air only, without arguments! You are throwing around words like nonsens, hammer and nails, blah blah - all indicators for the lack of arguments, not worth to respond to.
For those who are reading this thread and might be interested in the contents (not for hot air pilots!):

Record Level Access is outdated, since SQL came up to AS/400, its good old ISAM (index sequential access method) and SQL supports the relational approach. Tieing the application to the database happens by navigating thru the datatabase by moving key fields from one table to fields of another table to make a chain operation to read another table - its not the problem altering the scale of fields. Proper database design is always a picture of your business world at that time you designed your database and as time goes by, your business changes and the data model needs changes to follow the changes of your business and therefore you should decouple database and application, as far as it is possible.

SQL is a strongly typed language, each assignment, each comparisation between your host language and the SQL layer and each transfer of data between the database and the SQL interface is checked of type compatibility. RLA transfers binary huddle between the database and the application with higher risc of data corruption.

All default settings of SQL are prepared for using commitment controll and it's by far more easy to use commitment controll and you should use this, it's state of the art and data corruption, caused by not using commit blames the programmer, who didn't use it. updating data in normalized databases needs transaction controll anyway - and this would not work without commit. Applications running 24 hours a day, seven days a week need transaction controll, because there is no offline window for producing consistent reports.

Using two concurrent technologies to do the same, (DDS and DDL, or SQL and RLA) complicates application developments and the readability of code is worse, then concentrating on one of the technologies, so there is a decision to make between SQL and the native interfaces and I recommended and recommend SQL even thow it might be a little bit slower, or needs a little bit more hardware ressources (and in my experience, its slower and sucks some ressources!).

Finally, moving from DDS and RLA to SQL is a step in the direction of the mainstream of application development and could save your knowledge, if there will happen a move from AS/400 to another system (could happen, I've seen this sometimes last 20 years and nobody moving from something else to as400 since 10 years).

Dieter
--------------------------------------------------
From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
Sent: Monday, November 01, 2010 12:33 AM
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Subject: Re: SQL database object names longer than 10 characters and mixedcase?

On 10/31/2010 5:23 PM, Bruce Hoffman wrote:

Opposing view...

First, the obvious and probably not under dispute... ALL changes,
improvements, performance, advances are made only in SQL. Define all
tables in SQL DDL. IBM stated this more than a decade ago. This can be
done now, and does not require changing applications.

This is the only part of your post that actually has a basis in fact. I
agree, and have said this for a long time as well. DDL is (almost) a
superset of DDS and with better performance. Just make sure you use a
source file to create your tables and have that source under the same
version control as your programs. But your data definition approach has
exactly zero to do with your data access technology, and there is where
we differ really, really quickly.

Continued use of RLA for I/O, ties your database interminably to the
past and makes moving forward with your database no better than any
other time in the past since you are at the mercy of the format level
identifier. You are tied to the physical representation of your tables
and this is one of the reasons that people still see IBM i OS as "old
and outdated". It's also one of the tenants of Relational Technology...
separate your applications from the physical representation of the data.

Nonsense. In the first place, you shouldn't be making regular changes
to your database; ALTER TABLE is no substitute for good database
design. But let's assume that your design skills are so poor that your
database suffers for it and you have to change it regularly. Then at
least have the common sense to wrap your physicals in logicals and get
over your bad self. Hey look, ma! No format level identifier
problems! (That is, of course, unless you've designed your database SO
badly that you regularly have to change the attributes of your EXISTING
data fields even after they've gone into production. If that's the case
then you probably should consider broadening your employment horizons.)

As for the "old and outdated" bullpuckey, I assume you're telling
everyone to dump RPG as a development language as well, since it's old
and outdated. I haven't seen you advocating that Bruce, am I wrong?

While IBM i OS RLA applications call for recompilations every time we
make a change to the database, the Oracle, MySQL and SQL Server people
have already altered their tables and are accommodating requests for
change while we wait for a good time to take the machine "down" and
recompile the world.

More blah blah. Use logicals. Change the physical using CHGPF.
Everybody's happy. I can't believe it's 2010 and we're still having
this argument.

Additionally, you can't use index-only access from RLA. You can't take
advantage of EVIs. You don't have as much control over what fields are
actually retrieved and or updated by your applications.

Yeah, okay, a second valid point. But you see, unlike you I recommend
taking advantage of the incredible strengths and versatility of the IBM
i and use each technique as appropriate. I use SQL all the time, and I
also use RLA.

Just because you like the big shiny hammer of SQL doesn't make every
programming problem a nail, Bruce.

Use the right tool for the right job.

Save the database, save the world!

Joe

P.S. Dieter? *That's* a flame. You didn't even get a warm breeze...
<smile>
--
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: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.