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

Dave,

You keep saying this, but it simply isn't true. Oracle, you which consider a real RDBMS, is at least
one that provides for non-SQL access to the data.

Direct Path Load
A direct path load builds blocks of data in memory and saves these blocks directly into the extents
allocated for the table being loaded. A direct path load uses the field specifications to build whole
Oracle blocks of data, and write the blocks directly to Oracle datafiles, bypassing much of the data
processing that normally takes place. Direct path load is much faster than conventional load, but
entails some restrictions.

Actually when you read the above, Oracle's direct access bypassing the DBMS processing entirely
violates Codd's Rules.

Whereas, System I access via RPG which doesn't bypass the DBMS, DOESN'T.

Now for something really interesting that I ran across....

"complete rewrite of OLTP DBMS"

http://www.dbms2.com/2008/02/18/mike-stonebraker-calls-for-the-complete-destruction-of-the-old-dbms-or
der/

or http://tinyurl.com/2p8sp3


"There seem to be three main assumptions underlying the H-Store design, two of which Mike seems fairly
certain of, and the third of which he regards as subject to further research. The first assumption is
that there is no need any more for such a thing as a long-running transaction or cursor. Transactions
aren't held open any more for input from users at dumb terminals. Records aren't sent down in batches
to be scrolled through. Instead, transactions are fired off from web pages via internet protocols,
with results being sent back upon transaction completion.

This assumption has three major consequences. First, multi-threading is no longer needed. That gets
rid of huge overhead around connection pooling and b-tree consistency, to name just two areas. Second,
traditional locking isn't needed; H-Store relies on optimistic locking instead. Third, it's a really
pointless and high-overhead idea to call out to a separate data manipulation language like SQL.
Instead, Mike favors programming languages that mix data manipulation into other logic, like Ruby on
Rails (which will be used in the next iteration of H-Store), or the fourth-generation languages of the
1980s.

The second of H-Store's three big assumptions is that you can do without disks. Disk rotation is the
big technical bottleneck of database management. While most other measures of computing performance
double every 2 years or so, disk rotation speeds have only increased 12.5-fold in the past half
century. And unlike the case of data warehousing, the nature of OLTP makes it pretty impossible to be
disk-centric without doing huge numbers of random disk seeks."

Now I don't know about you, but as I read the above (haven't read the paper yet, by I've added it to
my todo) it seems to me that RPG on the System i with its single level store would be a pretty good
fit for the above.

Charles Wilt
Software Engineer
CINTAS Corporation - IT 92B
513.701.1307

wiltc@xxxxxxxxxx




This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.

This thread ...

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