Re: COBOL and DB2 vs. Java and DB2



"Judson McClendon" <judmc@xxxxxxxxxxxxx> wrote in message
news:ElyHi.61944$t9.21954@xxxxxxxxxxxxxxxxxxxxxxxxx
"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.
:-)

OK, that's a good explanation and I accept what you say, for that particular
environment.

Nevertheless, there is a lot going on in the world of data access at the
moment and SQL is probably going to be replaced by "storage and processor
independent" Query Expressions. I accept, that in non OO environments this
is unlikely to make much difference in the short term. In the long term it
almost certainly will, especially when people realize that the new
technology is many thousands of times cheaper and faster than existing
spinning platters.

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: CREATE AGGREGATE failed because type Concatenate does not conform to UDAGG specification due to
    ... Go to the Database tab and click on the browse button next to the connection string. ... In the New Database Reference dialog, enter the details for the database where you want to deploy the assembly and create the user defined aggregate. ... I'm trying to do some CLR integration with sql server 2005. ...
    (microsoft.public.sqlserver.programming)
  • Re: COBOL and DB2 vs. Java and DB2
    ... In the situations I am familiar with, traditional mainframe databases blow ... the doors off SQL type approaches. ... an SQL type approach (by which I take it you mean Relational Database). ...
    (comp.lang.cobol)
  • CREATE AGGREGATE failed because type Concatenate does not conform to UDAGG specification due to meth
    ... Now register the assembly and the aggregate in the SQL Server database you want ... I'm trying to do some CLR integration with sql server 2005. ...
    (microsoft.public.sqlserver.programming)
  • 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)
Loading