RE: Green screen - it's time is over

Don,

Good insight, but a little TOO concise.

XPATH!...?

Sheesh...  I never claimed I knew everything, but sometimes it's
discouraging to find out, each and every day, how much I don't know what I
NEED to know.  Gotta link...?

jt

> -----Original Message-----
> From: midrange-l-admin@midrange.com
> [mailto:midrange-l-admin@midrange.com]On Behalf Of Schenck, Don
> Sent: Wednesday, November 14, 2001 8:45 AM
> To: 'midrange-l@midrange.com'
> Subject: RE: Green screen - it's time is over
>
>
> SQL is yesterday's technology. It's like Hootie and the Blowfish.
>
> XPATH! That's like Ben Folds.
>
> <grin>
>
> -----Original Message-----
> From: Joe Pluta [mailto:joepluta@PlutaBrothers.com]
> Sent: Wednesday, November 14, 2001 8:43 AM
> To: midrange-l@midrange.com
> Subject: RE: Green screen - it's time is over
>
>
> I get sucked into this conversation every once in a while because I just
> can't stay away from it.  There are several ways to answer your question,
> and, despite my reputation, I'll try to be concise and outline just two.
>
> 1. Benchmarks.  I've released many over the last of year or so
> that show SQL
> to be anywhere from 50% to 500% slower than record level access, at least
> for database update.  For queries, it can be faster.  Whenever you talk
> about SQL performance, you really need to separate queries from database
> update.
>
> 2. Thought exercise.  Let's use common sense, just for a moment.  SQL uses
> all the same database routines as record level access.  The primary
> difference is something called a "query optimizer", which is what makes
> multi-file joins and some other set-based queries faster than traditional
> HLL approaches.  For updates, especially record-at-a-time updates like we
> normally do in transactions, SQL basically adds extra work (parsing the
> statement, determining column positions and the like) prior to
> executing the
> same database routines the HLL executes directly.  So, unless the SQL
> overhead actually executes in negative computer cycles, it will
> take longer
> than the HLL record level access.
>
> There are a few exceptions.  Queries that require accessing different data
> in different files based on the contents of a field are not particularly
> fast in SQL (not to mention that they can be a bear to code).  But in most
> cases it seems that the query optimizer does a good job of making data
> access faster in SQL.  On the flip side, there are occasional situation
> where SQL is better for database updates, usually in cases involving large
> blocks of records being updated.
>
> So, back to your situation, Rob.  Tell us a little more about the
> application, rather than simply saying "SQL is FASTER than traditional
> access", because the correct answer is (as usual in these things):
> "sometimes".
>
> Hey, that was reasonably concise!  I'm outtahere...
>
> Joe Pluta
> www.plutabrothers.com
>
>
>
> > -----Original Message-----
> > From: rob@dekko.com
> >
> > I don't buy your argument at all about SQL being slower.  A
> gentleman here
> > - and no SQL fan for sure - started using SQL just because it's
> > FASTER than
> > traditional access.  And he writes 'real world' code for ERP.
> He finally
> > messed with some blocking factors (much easier in RPGLE) and
> went back to
> > traditional access because now SQL was only FOUR times faster than
> > traditional access and that difference he could live with.
> >
> > Rob Berendt
>
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L)
> mailing list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>