× 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.



You're absolutely right, Dan.  I assume that I will be writing for the
AS/400.  Any other assumption is a poor one for my clients.

However, that's really not the issue here.  The issue is a broader one: is
SQL a valid approach when accessing AS/400 data from an OO language.  The
answer is a resounding NO!  Since he's writing in Java, he could easily
encapsulate the database access in an object.  In fact, I'm giving a class
on exactly that technique at COMMON.  Then, if for some reason you need to
access data on another database, you can attach a different data source and
your application won't know you changed.

Especially in an OO environment, it is never a valid argument to sacrifice
performance for the sake of "possible futures".  Since you can easily alter
the behavior of any class, you should always write for performance, but
encapsulate your code.

If you think about it, SQL, with all its inefficiency, was simply a first
attempt at encapsulating data access.  With true OO languages, the
requirement for this crude form of encapsulation has been removed, and so
the argument of "maybe someday moving to a different platform" is removed.
If you move to another platform, you'll have to rewrite your data access
objects, but that should be a relatively trivial procedure.  In fact, if you
want to have one version of SQL and one version of native access, you have
the best of both worlds.

If your idea of delivering quality product is to sacrifice real performance
for your user today for the sake of a possible easier conversion for
yourself sometime in the future, then I submit that perhaps your definition
of quality and mine are different.

You want the soapbox back?  <grin>

Joe


> -----Original Message-----
> From: Eyers, Daniel
>
>
> Not sure I agree with you here.  Your assumption is that you will *always*
> use the AS/400 for your hardware platform.  *and* you assume that you will
> *only* connect to AS/400s.  If I wanted to migrate my applications off the
> 400 onto some other package, I'd be hard pressed to convert the RPG and
> COBOL to some other language.  On the other hand, using the '400 as a
> development platform (and using SQL) allows me to offer systems on other
> platforms with little to no conversion.  Finally, using RPG and COBOL
> programs assumes that there is an adequate supply of COBOLers and
> RPGers.  I
> don't know about you folks but I *certainly* don't believe that to be the
> case.  In fact, the AS/400 program at the local community college
> is seeing
> significant decline in enrollment... one of the hottest classes:
> Oracle and
> SQL.
>
> Having said that, I think each shop should consider carefully the decision
> to use SQL or RPG and COBOL programs as their choice.  Performance is a
> crucial issue, however, I find I'm bound by bandwidth, not the response of
> the 400.
>
> (getting off my soapbox)
>
> dan



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.