Here we go again ...

On 08/03/2008, at 9:37 AM, Dave Odom wrote:

Sorry for taking so long to get back at you but, as I said, I had to build a pro-System i5 presentation about building a data warehouse in the i5. The audience were end users and developers that love MS Access, ORACLE and SQL Server. The presentation went well and the System i5 data warehouse project here is well underway with more wanting access or to put their data into it, as we "speak". It doesn't mean the whole war is won but a major battle along the way and things are looking good. Now to the answer I owe you for the statement I made about "DB2/400 is not a real RDBMS".

I'll provide you with SOME of the total answer to this as a full and complete answer would take an article or paper to fully discuss. Some of the answers are IBM some are how the system is used and some are the two different cultures (Real RDBMs culture vs. AS/400/System i5) Also, it would be VERY helpful to have a pretty thorough understanding of the RDBMS history, technical attributes of the most popular RDBMs, the accepted industry standards for how RDBMs are used, ANSI standards, and, most important, the marketplace for what is an acceptable and real RDBMS with regard to function, features, architecture, security, etc.

A typical question: "I have heard people state that DB2/400 meets more of the ANSI Standards for SQL databases than any other database on any other platform. Isn't that the standard by which to say what database is "best"?"

On this list we have pointed out your first sentence. That does not imply your second. What it means is that DB2 for System i is the most standards-compliant database available.


In the real world, not really. Those that look at buying an RDBMS look at several things and this is a partial list: functions,

DB2 for System i: Tick.

features,

DB2 for System i: Tick.

robustness,

DB2 for System i: Tick.

industry architecture compatibility,

DB2 for System i: Tick. (See point above about ANSI Standards--not platform or DB-specific extensions which you CONSIDER industry- standard.)

which leads into can I find personnel that have the education to create and maintain databases and applications against a particular RDBMS engine or how easy is it to train them,

DB2 for System i: Tick.

ease of care and feeding,

DB2 for System i: Tick.

reputation in the IT space,

DB2 for System i: Tick. (At least for those with the wit to see.)

how many vendors support with tools of various types,

DB2 for System i: Tick. (Most 3rd-party DB tools will work as expected against DB2 for System i even if the vendor has not explicitly tried that. All you need is access to the system catalogue tables and Rochester did work MANY releases ago to make that interface look like the one the tools expect.)

security

DB2 for System i: Tick. (Damn sight more secure than the alternatives.)

and price.

DB2 for System i: Tick. (Cost of entry is higher but TCO is much lower.)


Another typical question: "What is it that these other databases have that DB2/400 does not have that are useful for designing business application databases?"

Have another go. You failed to answer your own question. Most of your responses below are things System i HAS that the others HAVEN'T--they are not things these other databases HAVE that make them better!


- They (real industry standard RDBMs) are set up as a true RDBMS with TABLES, NOT files, VIEWS, NOT logical files, INDEXES, NOT logical files, etc.,

An externally-described System i file IS a table. A System i logical file IS a view. A System i logical file IS an index. Again your issue seems to be with terminology rather than function. THEY call it something else therefore WE have to too.

- TABLES can only be in table format, usually designed using third normal form to take advantage of the strengths of the RDBMS, NOT old style flat files, or multi-member files that access data via keyed access...

That's only because THEY DON'T HAVE THAT CONCEPT. Rochester took the RDBMS concepts and applied them to the system in such a way as to map SEAMLESSLY to traditional database I/O. That's a good thing--even though continued support for it makes it possible for developers to stick with what they know rather than being forced to learn so-called modern ways simply because they have no other choice. Your issue seems to be with backwards-compatibility--another good thing fairly uncommon amongst the alternative vendors.

there is NO SUCH THING as a file in DB2 or ORACLE and I think in SQL Server as well.
- Multi-member TABLES are not allowed in a true RDBMS.

What do you think partitioned tables are then? They might not be implemented as MEMBERS on other RDBMS but the concept is the same. Rochester took advantage of existing system technology to implement this concept. Why is that a bad thing?

Next you'll be telling us that Rochester should discard *FILE objects for SQL use and put the DB into the Root file system as a collection of stream files just like all the other RDBMS.

- SQL is the ONLY access language to get to the data, not some old record-at-a-time processing back door technique like READ, WRITE, CHAIN, etc.,

So what! That's a System i advantage. It's not a back-door technique either. All database access eventually goes through the same underlying interfaces. It gives CHOICE--something others don't have.

- ALL information about the structure of every TABLE, VIEW, INDEX, etc., in a SYSTEM catalog or tables, which are only accessed via SQL, not in each of the files themselves wherein you have to use a non-SQL command Display FILE FIELD Description or some such

Most of the additional information you want in catalogue tables is not standard SQL stuff anyway. It's all platform extensions. The others have to put it in tables because they don't have any other choice. Because tables are implemented as discrete OBJECTS on System i (another thing the others DON'T have) it makes sense to store information about an object IN THE OBJECT ITSELF. If you want it in a table you can put it in a table using a system-supplied command.

- the System Catalogs are many and robust, like in DB2 for VM or MVS or the V$ tables in ORACLE to support MANY types of database and application designs from simple tables to the storage of BLOBs, XML and much more.

DB2 for System i: Tick. (Again, most things System i doesn't support are non-standard extensions.)

- HUGE numbers of vendor tools are available for database design and build and reverse engineering, application design and build, performance tuning, and much more

Most of which work against DB2 for System i also.

- database has mechanisms for 24/7 operation WITH backup by being able to quiesce portions of the database for backup while the rest of the database is active

Never heard of Save-While-Active then?

- DBAs and application developers think and design only around TABLES, not files using record-at-a-time processing

Now we get to your real issue. As I said in a previous append (on 28- Feb-2008) your primary complaint is NOT that DB2 for System i is not a "real" database but rather that it supports alternative access to the SAME database as SQL **and** that many System i developers choose to use that alternative access rather than what YOU THINK they should be doing.

I can create a non-relational de-normalised set of tables using SQL on Oracle if I wish. Does that happen? Yes, when the DBA is inexperienced, has insufficient information, wants to extend a 3rd- party application without altering vendor tables, or deliberately uses 2nd normal form for performance reasons. None of that specific use makes their RDBMS of choice any less "real". Neither does the way some developers CHOOSE to use System i RDBMS make it any less "real".

- DBAs design TABLES using Referential Integrity and other functions on a regular basis such that many actions that once were done by the developers program are now done at the database level

DB2 for System i: Tick. (Many System i applications make use of these features but just as many choose not to. It is the fact that the SYSTEM provides support for RI that makes it "real" not that some developers CHOOSE not to use it.)

- Managers have an easy time finding personnel that can read, write and speak in SQL and industry standard RDBMS methodologies whereas they see folks that use RPG (they think that means Rocket Propelled Grenade) and CL (what's that) and SEU, PDM, etc. as being from an OLD, LEGACY system that is so out there in a vary narrow part of the world.

I don't have space to argue this properly. Yes, it is easier to find DBAs with experience on other platforms. Why?
One: Those platforms NEED a DBA. System i SHOULD have one but doesn't NEED one.
Two: Students are exposed to those other platforms during tertiary education.

Using SQL embedded in RPG or COBOL is no different from using SQL in, say, PL/SQL. They are both ways of programmatically accessing SQL.


- The real DB2s and ORACLE and SQLServer are well respected in the industry for these and many other reasons and DB2 and ORACLE run on many different OSs and MANY applications are built on those platforms
- and on, and on, and on

DB2 runs on WinDOS, Linsux, and *nix (LUW). Oh AND System i. Oracle, Sybase, Informix, SQL Server, etc. don't run on System i. Why? Because System i already HAS an RDBMS supplied in the base system. Ain't no point in competing ON the System i when they can compete AGAINST it with their existing code-base.


So, the IT industry, as a general and common rule, recommending a platform and an RDBMS to the CEO and CFO to buy will not even see the System i5 as in the running. This has to change if the platform and the jobs it supports are to survive. I hope it can be done. But the traditional System i5/AS/400 folks out there are going to have to come into the reality of the rest of the world and not only see things from their staid and outmoded perspective.

That has more to do with the ignorance of non-System i personnel (they only know LUW and RDBMS X so that's what they offer) combined with poor marketing from IBM (primary reason for which I've addressed in other appends).

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 / \
--------------------------------------------------------------------




This thread ...

Follow-Ups:
Replies:

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

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