|
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. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.