Re: help with tables
- From: Robert <no@xxxxxx>
- Date: Wed, 30 Jan 2008 17:57:20 -0600
On Wed, 30 Jan 2008 10:39:16 +0000 (UTC), docdwarf@xxxxxxxxx () wrote:
In article <15ovp3p40dmvcovmgc3co257gi595dn3ii@xxxxxxx>,
Robert <no@xxxxxx> wrote:
On Tue, 29 Jan 2008 19:05:40 +0000 (UTC), docdwarf@xxxxxxxxx () wrote:
In article <c7sup39sjmh3d0n70m26o05ql6np5igq5r@xxxxxxx>,
Robert <no@xxxxxx> wrote:
On Tue, 29 Jan 2008 14:51:50 +0000 (UTC), docdwarf@xxxxxxxxx () wrote:
In article <m6bup35nfg7lbr4fmtpk0hoa08j055hu9h@xxxxxxx>,
Robert <no@xxxxxx> wrote:
On Tue, 29 Jan 2008 08:11:32 +0000 (UTC), docdwarf@xxxxxxxxx () wrote:
[snip]
Things may have changed since I last looked, Mr Wagner - I've heard tell
that GOBACK is more than an IBM extension! - but I believe that 'bulk
collect' is PL/SQL, not ANSI.
That's a widely held mistaken belief, especially in Cobol circles. Bulk
collect can be
used with SQL embedded in Cobol, C or Java. It is not limited to PL/SQL.
(note - '-marks used to indicate a direct text quotations)
A programmer might read what was written carefully, Mr Wagner; I did not
say that 'bulk collect' was limited to PL/SQL, simply that it 'is PL/SQL,
not ANSI.' ('ANSI' is being used as a shorthand for 'ANSI SQL')
[snip]
You are putting words in my keyboard. I did not say anything about the
ANSI standarxd, I
said bulk collect is available in Cobol, it is not a PL/SQL feature.
According to
http://www.oracle.com/technology/oramag/oracle/04-jan/o14tech_plsql.html
'bulk collect' most certainly *is* available in PL/SQL:
--begin quoted text:
BULK COLLECT and FORALL are very helpful, not only in improving
performance but also in simplifying the code you need to write for SQL
operations in PL/SQL.
--end quoted text
... but what would Oracle know about the features of PL/SQL, anyhow?
If you don't like BULK COLLECT syntax, leave it out.
It may be less a matter of what *I* like, Mr Wagner, and more a matter of
what my client has asked me to do in exchange for my wages.
Requests I get depend on who within the client organization is asking.
Round one: applications wants a style based on the premise we might wake to find the last
25 years was a bad dream, the application has to run on a 1980's mainframe. They write
VSAM record processing logic in Cobol or PL/SQL.
Round two: administrators try to speed it up by adding parallelism on the server side, by
partitioning tables and indexes, launching parallel processes on the client side.
Round three: operations throws faster hardware at the problem.
Round four: management tries to make the problem go away by questioning why we need to run
the job, who authorized it, can the work be done another way, would it run faster in
another language, talks to salesmen about third-party products.
Round five: the client asks me to 'Make it run faster. We think all ya gotta do is
optimize the database.' Instead, I rewrite logic the way it should have been written in
the first place. Doing things right flies in the face of client culture, is used only as a
last resort.
I'm working on a weekly job that's been through rounds 1-4 and still runs longer than a
week. The rewrite runs in a half hour, as a single thread. The difference is set
operations rather than record processing, clean logic rather than tricks, it's written in
non-procedural SQL. Round one management would reject such an approach.
Selecting into an
array does the
same thing and isn't tied to Oracle.
This seems to be a kind of admission that your first example was PL/SQL,
as was pointed out a while back and specifically denied by you in what you
quoted ('... bulk collect ... it is not a PL/SQL feature.')
If ya wanna get technical, yes it runs through the PL/SQL engine on the server side, but
the client program need not be written in PL/SQL, it can be written in Cobol or C. All ya
gotta do is put the statement in a BEGIN .. END block.
Bulk collect gets a table with a single message to the server, a single trip through the
parser. Selecting into an array runs a cursor under the covers, causing a fetch for each
row or buffer. It's significantly faster than explicit fetches, but still slower than bulk
collect.
I forgot to show him the MAINFRAME WAY:
3100-SEARCH-TABLE2.
D DISPLAY 'IN 3100-SEARCH-TABLE2'.
MOVE WS-CONST-N TO WS-IND1.
PERFORM 5600-LOOK-IN-TABLE2 THRU 5699-LOOK-IN-TABLE2-EXIT
VARYNG WS-COMP-SUB2 FROM WS-CONST-1
BY WS-CONST-1
UNTIL WS-IND1 = WS-CONST-Y
OR WS-COMP-SUB2 > WS-COMP-TABLE2-SIZE
END-PERFORM.
That's similar to a way I have seen things done on mainframes, yes... but
a way that would not pass muster in more than a few shops where I've
worked and would have gotten you laughed out of Prod Implementation
reviews.
I've never seen a Prod Implementation review. I've only seen reviews BEFORE testing began.
Sounds like you're putting untested rewrites into production.
(if 3100- begins in column 8 (as indicated by the debugging line
following it) then the imperatives which follow precede column 12)
My keypunch machine was down.
.
- Follow-Ups:
- Re: help with tables
- From:
- Re: help with tables
- References:
- help with tables
- From: canela
- Re: help with tables
- From: Robert
- Re: help with tables
- From:
- Re: help with tables
- From: Robert
- Re: help with tables
- From:
- help with tables
- Prev by Date: compile+link Fujitsu Linux
- Next by Date: Re: OT: Racial superiority / Intelligent design was Re: OT:Thanksgiving
- Previous by thread: Re: help with tables
- Next by thread: Re: help with tables
- Index(es):
Relevant Pages
|
