× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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>

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.