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.