Re: Sybase vs Oracle - which is better?

Sorry, but I can't find the original post. Guess it wasn't posted in comp.databases.oracle.server :)

>>Paul Mapstone wrote in message <365997B8.6B605638_at_t-mi.com>...
>>After a gap of 8 years I recently had the misfortune to need to use
>>Oracle for a while. It has come a long way with its performance, stored
>>procs, triggers, PL/SQL in the server, etc. However, I noticed the
>>following important facilities were still missing:
>>
>>1. Cannot do a DELETE with a join or correlated sub-query.
That is an invalid statement.
Correlated sub-queries are no problems and hasn't been since version 5 where I started using Oracle. The join has some restrictions but using a view would allow you to delete from the "master" table.

>>2. No Sybase style temporary tables.

Correct - but why use them when SQL can do it for you without problems? With internal tables in PL/SQL the need I've had in the past to temporarily save a few hundred or thousand rows can now be done internally in memory. I guess it all comes down to how your technology defines your way to work. In Oracle you seldom have the need to create temporary resultsets in a table.

>>3. Cannot easily create and use a table in a stored procedure, temporary
>>or not.

Huh? Easily is a way of interpretting and is relying on a subjective evaluation.
Can you give some examples of this?

>>4. you cannot write a stored proc to return result rows (yes, I know you
>>can return a REFCURSOR, but that is nowhere near as useful).
And you can return PL/SQL tables (internal tables). This is actually interpretted by ODBC as a dataset. A "row of records".

>>I believe that 1-3 above are the reason why so much Oracle code requires
>>cursors. Problem 4 results in a lot more SQL being embedded in
>>applications, rather than in stored procedures, which makes tuning
>>harder.

Again, a matter of interpritation. Tuning does not become harder because you use SQL instead of stored procedures. I would argue, that you have a wasted amount of processing because you try to share data access path in a stored procedure, fetching and doing calucations that are not really necessary. Working on datasets selected 1 or 10 seconds ago is not an option in OLTP systems. Hence I prefer to do my select and work on the data as fast a possible.

I have no interest in participating in the rowlocking vs. block based access that keeps appearing every couple of months in these groups. I think the matter has been argued to death - and all the conclussions end up with: Both have their advantages and disadvantages - depending on the situation. DUH!

Regards
  Peter H. Larsen
  Senior Oracle Consultant Received on Wed Nov 25 1998 - 00:00:00 CST