|
> From: Dave Odom > > Any file that is not created with any "depth", nor relational, nor > hierarchical in structure is a flat file, regardless of the numbers or > sizes of fields; i.e. IMS, DB2, Oracle and the like. Most files on the > iSeries, MVS, VM, VSE, PCs, etc. are flat. These words have no intrinsic meaning, and your use of the term flat file is incorrect. Please define exactly what characteristic gives a file "depth", and how that is not supported in DB2. > Oh, my, I have just committed blasphemy, at least per Rochester and > those that follow their dogma. No, you're just making up and/or mis-defining terms. > I know, I know, IBM Rochester has told you for decades the S/38, > AS/400, iSeries, etc., is a relational database. I believed that as > well back in 1984 after being indoctrinated by the S/38 folks in IBM > classes. But sadly, it was and is not true. Name a database that is relational. Identify which of the Codd rules it follows that DB2/400 does not. > Secondly, the rest of the > relational community does not consider the iSeries to be a relational > database machine nor have a true and complete relational database > architecture for storing data. By definition, an RDBMS doesn't CARE how the data is stored. "Relational" cares about how the data is accessed, not stored. An RDBMS can store the data in comma-delimited text files as long as it has the proper relational access (and in fact, tinySQL does just that). > And the faster Rochester gets in step with the > relational world, the better off it will be for the iSeries world and > its followers so it can compete with the real DB2s, Oracle and other > relational worlds. Where don't we compete? As far as I know, DB2/400 is completely ANSI compliant. Please explain where it falls short. Anything that is NOT an ANSI standard is a vendor-specific extension, and as I've pointed out, even the simplest of extensions vary wildly from one vendor to another. For example, the syntax for getting the first 5 rows from a given SELECT statement is different for every major vendor. > But the bottom line is, the iSeries community and IBM Rochester has to > stop being so proprietary, needs to follow the essential tenets of Dr. > Codd's Rules and act more and more truly relational. As I just pointed out, anybody who points to Codd's rules as the standard of whether a database is an RDBMS doesn't understand that NO database completely adheres to the rules. 3, 5, 6 and 12 tend to exclude every database one way or another. > But as it is > not seen as truly relational by those looking to buy and therefore loses > out to Oracle and SQLServer, I think everyone in the iSeries community > better forget the dogma of the past and realize what the OS and its > legacy file structure is not; not relational but usually flat. Once again, this is a mis-definition of the words relational and flat. DB2/400 follows just about as many of Codd's rules as any other major database and is just about as ANSI-compliant. It may lack in extensions, but that's always been an issue: do you stick with the standards, or create extensions which then must be grandfathered into your code when the real standards come out? I'm willing to bet you that not all syntaxes of getting the first rows of a SELECT will be supported, which means some vendors will have to either remove functionality or support non-standard syntax. Joe
As an Amazon Associate we earn from qualifying purchases.
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.