Re: COBOL and DB2 vs. Java and DB2

"Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
"Judson McClendon" <judmc@xxxxxxxxxxxxx> wrote:
"Robert" <no@xxxxxx> wrote:
"Judson McClendon" <judmc@xxxxxxxxxxxxx> wrote:

In the situations I am familiar with, traditional mainframe databases blow
the doors off SQL type approaches. Whoever designed SQL must have
been entirely clueless, or indifferent, to machine efficiency.

Everyone who's run a Google search knows that to be untrue. It displays the time it spent
searching three billion Web pages. I just did it with four wildcard words -- "for * * nail
the * was lost". It found 27,000 in .08 seconds. That's fast!

Yes, and how many shared servers does it require to achieve that, eh?
My point was about hardware efficiency. If it takes 20 computers to
do what one could do using another approach, then it is less hardware
efficient.

Judson, you may be over-reacting here (Robert's posts often have that effect on people :-)) and losing sight of the actual
argument.

If those 20 computers each cost less than one twentieth the cost of the single computer, then your case is not made.

Actually, it is. My point wasn't about cost, or "best", but simply that SQL
was not nearly as efficient (fast) as traditional mainframe databases. :-)

While I'm here, I would point out that your statement above regarding SQL is at best provocative, at worst, simply untrue.

If, by "traditional mainframe databases" you mean VSAM datasets connected together, or (I seem to recall your background is
Unisys?) perhaps indexed random files in a FORTE style database, then it is very arguable whether these would "blow the doors off"
an SQL type approach (by which I take it you mean Relational Database).

There was a time when this MIGHT have been true, but that time is long gone. Certainly, a well designed "Traditional" DB
benchmarked against a poorly designed RDB will not fare well (I know, because I used the performance argument to enable a certain
company to hold onto their existing VSAM and resist RDB, but that was 20 years ago...)

I don't mean relational databases, I mean SQL, period. I'm talking about the
way SQL is designed to operate and be used. The mainframe database I'm
most familiar with is DMSII, which I would call a traditional mainframe
database. Files (tables) are created with one or more specific keys to access
them. DMSII is a relational database. There are many applications, particularly
ad-hoc type queries, where SQL would provide a more flexible tool. But for
batch processing, or for static (pre-designed) queries, there is no way in this
universe that SQL can provide a faster, more efficient tool, than a well
designed database using something like DMSII, because there is a lot more
overhead in the way queries are made and processed with SQL. Saying that
enough hardware to do the job could be assembled misses the point I was
trying to make. The point of hardware efficiency is needing less hardware. :-)

That's not to say that SQL is bad, or that I don't like it for the things it's
good for. But using SQL for those particular types of applications I
mentioned above means you're going to use a whole lot more hardware to
do the same job.
--
Judson McClendon judmc@xxxxxxxxxxxxx (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."


.

Relevant Pages

  • Re: COBOL and DB2 vs. Java and DB2
    ... the doors off SQL type approaches. ... was not nearly as efficient as traditional mainframe databases. ... whether these would "blow the doors off" an SQL type approach (by which I ... take it you mean Relational Database). ...
    (comp.lang.cobol)
  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... But SQL does not have a pointer data type or the ... > being told to design a database. ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)
  • Re: DBMS and lisp, etc.
    ... Naively implemented with SQL, again for 10 ... (1 query for the initial orders, 1 query for each order for its ... soon as you upgrade to the SQL database. ... (eq (order-customer orderA) ...
    (comp.lang.lisp)
  • Re: dbdebunk Quote of Week comment
    ... > a lot of really bad SQL programmers. ... a surrogate key should support the primary key. ... But SQL does not have a pointer data type or the ... > being told to design a database. ...
    (comp.databases.theory)
  • Re: dbdebunk Quote of Week comment
    ... But SQL does not have a pointer data type or the ... More and more programmers who have absolutely no database training are ... But why is little Cindy Lou Who employee ...
    (comp.databases.theory)