Re: Slight "I have some string, how lng it it, BTW, it's blue" question

Andrew wrote:
"Brian Peasland" <oracle_dba@xxxxxxxxxxxxxxxxxxx> wrote in message
news:J0HyE7.xG@xxxxxxxxxxxxxxxxxxxxxxxxx
: If you use a view and query from the view, you are using a SQL
solution.
: Using cursors to do your join will usually be slower than doing it
with
: a well-formed SQL statement.

can you expand on what you mean by 'Using cursors to do your join'? are
you
really indicating using more than one SQL statement and somehow
performing
the join programmatically? after all a 'join' is by definition down
within a
SQL statement which is run within a cursor -- so what am i missing here?
You'd have to ask the OP. It was he who said "Sorry it this isn't clear
- the reasoning behind
some of the use of cursors to mimic joins is way beyond me." I'm
assuming that he is processing
the join programmatically, but that is just an assumption.

Cheers,
Brian

Well - it's a trivial join n most respects. I'm now a grunt - but used to
call the shots as far as standards went. One stamdard was - "Use a cursor
when you can avoid it, kiss your arse goodbye"
To put the point bluntly - I'm baffled by the concept that rather than use a
well structured set of views - you basically write COBOL in PL/SQL

As well you should be. As I stated before....if you can do it in SQL, choose that approach over PL/SQL. Most every time, SQL will beat PL/SQL. I cannot think of an exception to this rule, but I'm leaving open the possibility that someone will come up with that exception.

OK - if you get paid, you do what you're told - but #i consider it to be a
personal affront - and would like ammo to try and change it. Hell - our
hardware supplier must be making a fortune we should not be paying on the
back of this approach.
Even more than SQLServer on NT - I'd expect huge gains with cunning ( or
totally bleeding obvious) use of the parallism you can get by splitting
queries over several views. Seems a no brainer to me - but apparently I'm
wrong.


Oracle will merge views by default. So if you have a view call a view, and your write SQL to reference the first view, Oracle will merge all the views into your SQL statement and then execute the entire thing as one large SQL statement.

HTH,
Brian


--
===================================================================

Brian Peasland
oracle_dba@xxxxxxxxxxxxxxxxxxx
http://www.peasland.net

Remove the "nospam." from the email address to email me.


"I can give it to you cheap, quick, and good.
Now pick two out of the three" - Unknown
.

Relevant Pages

  • Re: Teaching Oracle PL/SQL class
    ... I am teaching an Oracle PL/SQL class. ... Common Uses? ... Tight Integration with SQL / Higher Productivity ... Parameterized Cursors ...
    (comp.databases.oracle.server)
  • Re: Teaching Oracle PL/SQL class
    ... I am teaching an Oracle PL/SQL class. ... Common Uses? ... Tight Integration with SQL / Higher Productivity ... Parameterized Cursors ...
    (comp.databases.oracle.server)
  • Teaching Oracle PL/SQL class
    ... I am teaching an Oracle PL/SQL class. ... Common Uses? ... Tight Integration with SQL / Higher Productivity ... Parameterized Cursors ...
    (comp.databases.oracle.server)
  • Re: Slight "I have some string, how lng it it, BTW, its blue" question
    ... the rule of thumb I use is if it can be done with SQL ... If not, then use PL/SQL. ... can you expand on what you mean by 'Using cursors to do your join'? ... flexible that a COBOL programmer can write COBOL in PL/SQL. ...
    (comp.databases.oracle.misc)
  • Re: C5 Error on one record
    ... Packed the tables and then rebuilt the indexes from scratch I did not use REINDEX. ... The code was originally always crashing on the same line of code which was a SUM command, I changed that to a SCAN ... One thing I failed to mention was the data is copied from the three tables into cursors with SQL SELECT statements so the data they are working with is in cursors and not the actual tables themselves. ...
    (microsoft.public.fox.programmer.exchange)