Re: Sybase buys Powerbuilder - Is Oracle Dead?

From: Lawrence James <James.Lawrence_at_epamail.epa.gov>
Date: Tue, 29 Nov 1994 09:42:58 GMT
Message-ID: <James.Lawrence.30.0009B7A4_at_epamail.epa.gov>


In article <CzzJD0.7Ir_at_sybase.com> David.Heller_at_sybase.com writes:
>From: David.Heller_at_sybase.com
>Subject: Re: Sybase buys Powerbuilder - Is Oracle Dead?
>Date: Mon, 28 Nov 1994 17:50:14 GMT

>If you Oracle users and fans are going to crosspost to the Sybase group, be
>prepared for corrections and critique.
 

>How are Oracle stored procedure calls more flexible than Sybase's? Can you
>give some examples?
 

>I was told that Oracle stored procedures, can only return a single row. Is
>this true? Sybase stored procedures can return multiple rows (without
>resorting to temp tables or other workarounds). Do you really consider the
>ability to return only a single row MORE flexible? The most important point of
>relational database operations is, IMHO, working with sets of rows, not row at
>a time processing.

I've seen this type of argument too many times. The fact is most of it is subjective. The outcome of such comparisons is based on the level of importance that is put on each capability. I've no doubt that someone could say that Oracle's ability to group procedures into packages or Oracle's use of one language in both it's tools and database procedures is more important. It goes on to the next level and one could say that Oracle's ability to manage multiple cursors through a single connection or Oracle's transactional control and read consistency are more important that stored procedures anyway.

Obviously Sybase is a good product or it would not be around at all. However to take the Oracle position in this argument I would say check the single non-subjective measure I know, market share. The rest doesn't matter, want proof, look at MS-Windows.

Lawrence....

>In article <hackCzq75G.GDt_at_netcom.com>, <hack_at_netcom.com> writes:
 

>> if you want replication server, Sybase does that too.
>> If you want parallel server, use Oracle. If you want
>> flexibility on your stored procedure calls, again, choose
>> Oracle.
>>
Received on Tue Nov 29 1994 - 10:42:58 CET

Original text of this message