RE: Green screen - it's time is over

Joe --

"Shhhhhh ..." ... you're giving away my secret.

I do that on purpose, so people will hurry over to Google.com and search.

XPath is the "SQL of XML", if you will. Allows you to search and traverse
XML documents.

Start here:

http://www.topxml.com


Ain't computers fun? We can NEVER learn it all!

-- Don



-----Original Message-----
From: jt [mailto:jt@ee.net]
Sent: Wednesday, November 14, 2001 8:56 AM
To: midrange-l@midrange.com
Subject: 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.
>

_______________________________________________
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.