I enjoy collecting quotes and one that seems to apply to many RDBMS users (though I want to quickly point out that I do NOT believe it applies to Dave) is from the English philosopher Herbert Spencer:

"There is a principle which is a bar against all information, which is proof against all arguments, and which cannot fail to keep a man in everlasting ignorance -- that principle is contempt prior to investigation."

Way, way too many "RDBMS people" discount the System i without any personal knowledge or investigation. I know I've talked with some...

Unfortunately I will also point out that this seems to apply to all too many System i users also :-( Why else would we still be seeing OPM RPG questions, resistance to free from ILE RPG, etc. And, not to ignore Rochester, there are also "purists" in i5/OS development who take an approach similiar to "if it's not in the standard we're not going to do it" without investigating the merits of thinking outside the box.

To quote again from Herbert Spencer:

"Opinion is ultimately determined by the feelings, and not by the intellect."


Bruce Vining
http://www.brucevining.com/
Integrated solutions for the System i user community

Simon Coulter <shc@xxxxxxxxxxxxxxxxx> wrote:

On 28/02/2008, at 10:00 AM, DeLong, Eric wrote:

I'm really not trying to start a fight on this, but I have yet to
hear your definition of what constitutes a "real RDBMS". All I
have ever heard from you on this is "DB2/400 is not a real RDBMS".
Can you qualify that statement with real details?

I know I shouldn't answer a question specifically directed at someone
else but since Dave hasn't properly answered I'll tell you what I think.

Seems to me that Dave's issues with the i5/OS RDBMS are simply that
it allows alternatives not supported on the other so-called "real"
databases:

1) i5/OS RDBMS supports an alternate DDL therefore the database is
not required to be defined in SQL therefore it's not "real".

2) i5/OS RDBMS supports an alternate DML therefore application
programmers are not required to use SQL to access the data base
therefore it's not "real".

3) i5/OS RDBMS supports non-relational processing via multi-format
logical files therefore it's not "real".

4) i5/OS allows the database to run WITHOUT logging (i.e.,
journalling) enabled therefore it's not "real".

5) Finally, i5/OS allows traditional applications and files to
coexist with applications using modern, normalised database tables
therefore it's not "real".

Dave, and the countless thousands of Oracle/Sybase/Informix/SQL
Server dweebs consider this an indication of a flawed RDBMS
implementation because those supposedly "real" systems CANNOT do
this. Because they CAN'T do it they don't appreciate it and they
presume there is no merit in a system that DOES allow such behaviour.

While there are applications currently running on i5/OS that do not
take proper advantage of the database, do not use normalised tables,
etc. this does not preclude applications that are properly designed
and there are many instances of these too. Even if they use record-
level access the database can still be properly designed to satisfy
relation tenets.

The fact that i5/OS allows both SQL and non-SQL access to the same
files/tables is an advantage the other RDBMS do not have. Because
they don't have it they fail to see the benefit. We, enlightened few,
of course know better.

Neither can one look to the thousands of installed Oracle/Sybase/
Informix/SQL Server sites and say "Well, there are so many of them
they must be better for the business than the alternative". What
makes other RDBMS successful is simply marketing. That's why WinDOS
is successful and OS/2 has faded into history (although there were
other contributing factors in that saga--deceitful practices, lazy
vendors, a company that wanted to have its cake and eat it, etc.)
Nothing to do with technical merit.

Very few IT purchases are based on technical merit any more.
Intelligent decisions will be based on an application's suitability
for the business. This sort of decision is usually made by users and
management types--not technicians. Once the application is chosen
then the database and hardware are chosen. Not all purchases are made
so intelligently.

Of course, some sites look for an application/database that runs on
the hardware they already own, or an application that runs on the
RDBMS they already own. But still, even if they choose DB2 for Unix,
this still doesn't allow record-level access to SQL databases because
the underlying system has no concept of anything but stream files.
Even if you wanted to do ISAM on Unix you'd have to buy or write
something to provide that layer on top of the rather basic stream
file concept. Obviously this can be done but no-one bothers because
in that environment an SQL database is a better choice--both for
technical and business reasons.

It could be argued that SQL is also a better choice on i5/OS but
we've all seen evidence to the contrary. That's not to say that
record-level access is better either. They both have their place and
i5/OS is the ONLY system that lets you choose!

One other contributor to the success of the other RDBMS is that they
all have some flavour of GUI that is perceived to be native. This
appeals to the decision makers in the user and management group
because they like pretty interfaces. The fact that the interface runs
on the same platform (even if not the same system) as the database
contributes too. AS soon as you move the interface to another
platform (e.g., WinDOS in the case of i5/OS) one must ask why not run
the database there too. And vendors who make that move then consider
the database as a plug-in component and write to the lowest common
denominator and thus take no advantage of "different" things that i5/
OS has to offer.

I do agree with Dave that i5/OS application databases could often be
better designed, and that this may contribute to a poor opinion held
by other RDBMS administrators, but it is equally possible to design
bad databases in other RDBMS too. Perhaps his real issue is with the
fact that i5/OS does not require a TRAINED RDBMS administrator and
therefore many i5/OS programmers do not apply relational principles
and therefore design "bad" databases. If so then that does not make
DB2 for i5/OS any less of a "real" RDBMS than the others. If I misuse
a chain-saw it is because I'm an idiot, not because the tool is bad.

IBM (as in Corporate rather than Rochester) have been moving down the
"me too" path with support for PASE, AIX, Linix, HMC, etc. Instead of
trumpeting the advantages of the very things that make i5/OS
different (and better) they are involving themselves in a "Red Queens
Race". Perhaps when i5/OS is relegated to a guest OS running under
control of some flavour of Unix (HMC is Linux and "controls" i5/OS so
not an impossible idea), all applications run under PASE or AIX/
Linux, and there is no technical advantage to i5/OS because now it's
just like all the others Dave and his countless thousands will be happy.

In my opinion IBM will not allow i5/OS to be properly marketed for
two primary reasons:

1) It requires much less in services than the alternatives and the
big money is in services.
2) It is an integrated system that is clearly better for the
customer but IBM cannot say so without raising questions about the
suitability of the other IBM platforms.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------




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.