HP3000-L Archives

March 2001, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Shahan, Ray" <[log in to unmask]>
Reply To:
Shahan, Ray
Date:
Thu, 8 Mar 2001 07:57:01 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (99 lines)
Recall that the premise was for both the SQL and IMAGE DB's, the programmers
were "good at their craft".

        -----Original Message-----
        From:   Ken Hirsch [SMTP:[log in to unmask]]
        Sent:   Thursday, March 08, 2001 8:50 AM
        To:     [log in to unmask]
        Subject:        Re: Expensive RDBM Systems (Oracle)

        How often is this true?  Especially, how often in actual practice is
the
        work of the SQL optimizer worse than a programmer.  I've read lots
of bad
        Image code in my days.



        ----- Original Message -----
        From: "Shahan, Ray" <[log in to unmask]>
        To: <[log in to unmask]>
        Sent: Thursday, March 08, 2001 9:31 AM
        Subject: Re: Expensive RDBM Systems (Oracle)


        > The reason it's true is merely a result of the SQL optimizer (and
all
        > RDBMS's have them) ending up doing some/all serial reads for the
data
        > retrieval since the optimizer can't always correctly resolve all
of the
        > conditions that were set at the SQL call.
        >
        > The IMAGE calls would be coded by the programmer, and therefore,
only
        > require the reads necessary to retrieve the data required.
        >
        >         -----Original Message-----
        >         From:   Ken Hirsch [SMTP:[log in to unmask]]
        >         Sent:   Thursday, March 08, 2001 8:18 AM
        >         To:     [log in to unmask]
        >         Subject:        Re: Expensive RDBM Systems (Oracle)
        >
        >         Shahan, Ray <[log in to unmask]>:
        >
        >
        >         > Given 2 programmers, 1 for IMAGE and 1 for an RDMS, and
that
        both
        >         > programmers are very skilled at their craft:
        >         >
        >         > Try coding an SQL call for several tables/indexes using
        > 'inner/outer
        >         joins'
        >         > that also require some 'where not exists', and then
maybe one or
        > two 'or'
        >         > conditions sprinkled with a juicy 'and' relation...not
only is
        it
        > more
        >         > difficult to code, but It's sure to kill the machine,
any
        > machine...every
        >         > time.
        >         >
        >         > I know some of you will answer that IMAGE will run slow
too,
        given
        > all the
        >         > same paths, and you'd be right, but it wouldn't run near
as
        > slow...not
        >         even
        >         > close.
        >
        >         I have never seen evidence that this is true and I doubt
it very
        > much.  Why
        >         do you think this is true?  In the only published article
I've
        seen
        > where an
        >         application system was converted from Image to a
relational
        database
        > system,
        >         the relational DBMS was faster.
        >
        >         If somebody has benchmarks showing Image is faster for
some class
        of
        >         transactions or queries, go ahead and publish them.
        >
        >         The SQL has further advantages.  It is much more
independent of
        > database
        >         structural changes than Image intrinsic calls are.
        >

ATOM RSS1 RSS2