|
midrange.com
It's been my experience that traditional languages are performance hogs, if
done poorly and on improperly sized machines. I would recommend SQL.
Setup right, with properly defined views. On a properly sized machine.
For example, given the following, a 1,000,000 record file with a 32,000
byte field. In this field may be the value 'Mayberry' scattered throughout
the string. Now imagine 10,000 hits of Mayberry. Some, at the start, some
at the end of the field and the rest start at various positions within the
field.
Which will run faster?
SELECT * from TABLE where FIELDA LIKE '%Mayberry%'
or an RPG equivalent?
Rob Berendt
==================
Remember the Cole!
Richard Reeve
<richreeve@yahoo.co To: MIDRANGE-L@midrange.com
m> cc:
Sent by: Subject: Re: Evaluate
complex conditions
owner-midrange-l@mi
drange.com
10/26/00 03:10 PM
Please respond to
MIDRANGE-L
My experience is that both SQL and Query when run
interactively are tremendous resource hogs. Both
should be run in batch or if interactive at a lower
priority/timeslice than other interactive jobs.
--- booth@martinvt.com wrote:
> You suggest that an SQL process is not a performance
> pig compared to
> properly written RPGIV program. Is there any
> experience out there to
> support or confute this?
>
> I ask because we notice that whenever one of the SQL
> gurus starts an SQL
> process off the command line all the rest of us
> might as well go for
> coffee until the SQL is done.
>
> _______________________
> Booth Martin
> Booth@MartinVT.com
> http://www.MartinVT.com
> _______________________
>
>
>
>
> Marco Facchinetti <facchinetti@yahoo.com>
> Sent by: owner-midrange-l@midrange.com
> 10/25/2000 05:28 AM
> Please respond to MIDRANGE-L
>
>
> To: MIDRANGE-L@midrange.com
> cc:
> Subject: Re: Evaluate complex
> conditions
>
> Martin, if your purpose is a Query Tool my
> experience says
> that is better find something ready on the market.
> About performance: if an sql statement is too heavy
> the
> same one done in (eg.) RPG will take a very long
> time to be
> executed. If you got the right logical files defined
> in you
> DB you'll get good performace if not....
> Anyway if your are looking to eval or check an
> expression
> just remember tha procedure calls can be recursive,
> so you
> don't need any stack, procedures do it for you.
>
> Enjoy...
>
> --- booth@martinvt.com wrote:
> > I have 4 problems with an SQL solution.
> >
> > 1-I don't know SQL well enough to write the
> strings on
> > the fly.
> > 2-Users I know can't fill in a command line string
> > suitably for an SQL
> > solution,
> > 3-the few instances of SQL selections I've seen
> have
> > performance pigs in
> > that SQL would suck in the sides of the machine in
> an
> > interactive job, and
> > even with that still respond slowly.
> > 4-giving users full flexibility with and/or
> selections
> > just doesn't work
> > well. Their intentions are good but the example
> given
> > yesterday is a
> > wonderful example of the problem. ( "give me all
> > registered voters in New
> > Hampshire and Vermont" will list just a few
> energized
> > citizens that like
> > to vote early and vote often.)
> >
> > imho
> > _______________________
> > Booth Martin
> > Booth@MartinVT.com
> > http://www.MartinVT.com
> > _______________________
> >
> >
> >
> >
> > Marco Facchinetti <facchinetti@yahoo.com>
> > Sent by: owner-midrange-l@midrange.com
> > 10/24/2000 03:34 AM
> > Please respond to MIDRANGE-L
> >
> >
> > To: MIDRANGE-L@midrange.com
> > cc:
> > Subject: Re: Evaluate complex
> conditions
> >
> > SQL?
> > --- booth@martinvt.com wrote:
> > > Terry, the only method I've been able to create
> and
> > then
> > > understand again
> > > a week later, is to make a series of
> subroutines. Each
> > > subroutine will
> > > have a test for a condition and will flip a flag
> if the
> > > condition is not
> > > met. Something like this:
> > >
> > > C Eval DoItFlag = 'Yes'
> > > C Exsr Test1
> > > C If DoItFlag = 'Yes' And Test1Flag
> = 'Yes'
> > > C EXSR Test1SR
> > > C End
> > > C If DoItFlag = 'Yes' And Test2Flag
> ='Yes'
> > > C EXSR Test2SR
> > > C End
> > > C If DoItFlag = 'Yes' And Test3Flag
> = 'Yes'
> > > C EXSR Test3SR
> > > C End
> > > C If DoItFlag = 'Yes'
> > > C EXSR OKToDoSR
> > > C End
> > >
> > >
> > > _______________________
> > > Booth Martin
> > > Booth@MartinVT.com
> > > http://www.MartinVT.com
> > > _______________________
> > >
> > >
> > >
> > >
> > > Terry Grider <tgrider@arkansas.net>
> > > Sent by: owner-midrange-l@midrange.com
> > > 10/23/2000 12:43 PM
> > > Please respond to MIDRANGE-L
> > >
> > >
> > > To: MIDRANGE-L@midrange.com
> > > cc:
> > > Subject: Re: Evaluate complex
> conditions
> > >
> > > Sorry guys, I didn't do a very good job of
> explaining
> > > what I was looking
> > > for.
> > > I don't mean I want code that is an example of
> testing
> > > for complex
> > > conditions, I
> > > mean I'm looking for code that will evaluate
> statements
> > > like the one in my
> > > original example and determine the truth of the
> > > statement. You see, I'm
> > > writing
> > > a query tool and I want the user to be able to
> provide
> > > selection criteria
> > > in an
> > > english style IF format similar to cobol or
> other query
> > > tools I've seen. I
> > > can
> > > currently handle simple criteria with "and/or"
> > > connectors, but I can't
> > > seem to
> > > come up with a good method for handling multiple
> levels
> > > of parenthesis.
> > >
> > > Terry Grider wrote:
> > >
> > > > Has anyone ever written or seen an example of
> program
> > > code designed to
> > > > evaluate complex conditions? For example, if
> you
> > > wanted to evaluate a =
> > > > b and (c = d or c = e or c = f). I'm looking
> for
> > > something that can do
> > > > multiple levels of parenthesis and all
> "and/or"
> > > combinations.
> > > >
> > > > --
> > > > Terry Grider
> > > > tgrider@arkansas.net
>
>
=== message truncated ===
=====
__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf! It's FREE.
http://im.yahoo.com/
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---
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.
