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:
Ken Hirsch <[log in to unmask]>
Reply To:
Ken Hirsch <[log in to unmask]>
Date:
Thu, 8 Mar 2001 09:18:17 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
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