Re: Differences between the Microsoft and the Oracle SQL server

In article <4qp6om$ic1_at_ornews.intel.com>,

        ray charbonneau <raycharb_at_teleport.com> writes:
>>Now given this? Wheres SQL Server? ORACLE also runs on many of not all OS and
>>platforms and is rather scalable.
>>Bottom LINE: At the enterprise level, Oracle is tough to beat
>
>I have many concerns when considering Oracle. I do agree that from an
>enterprise stanpoint (especially if you are doing transactions over
>multiple databases), Oracle may be the way to go. But, there is a steep
>price to pay. First, you have to deal with Oracle.

OK, but OTOH, you're recommending that one deal with a company with a worse reputation than IBM in the 1960s for responsiveness to customers???

> Second, the product
>is more difficult to learn.

Perhaps this is true for the 30% solution. I'd call them comparable in learning curve, if you're only looking for about an 80% solution to your problem. But as you head toward the complete solution, MS starts having an exponential learning curve. Certainly, for application programming, I suggest that the enhanced functionality of ORACLE significantly reduces the project time-line.

> Third, the SQL capabilities in
>Oracle stored procedures are somewhat limited. Last time I looked, you
>could not create temporaray tables in a stored procedure.

That kind of suggests that your knowledge of ORACLE dates back to about 1992, doesn't it? We have an application that generates, populates, and drops hundreds of temporary tables per hour, with table_names that will NOT cause name reuse for several hundred million transaction cycles.

> You also could
>not join tables on Updates & Deletes.

Basically true, up until 7.3, at which point this criticism is gone. Current ORACLE is at 7.3.

> Also, Oracle's query optimizer is
>still not up to speed with Sybase and Microsoft.

I've heard this from MS idiots, yet not one challenge in my work environment has come even close to proving this one, in fact most have shown that the claimants are putting reliance on advertising, and not on any measured performance. The most I will grant you is that queries CAN be developed on MS that will actually optimise better, but that is the real exception.

In addition, particularly with MS, you must physically implement objects (i.e. indices), which a DBA can prove will never be used (other that to tie up disk and cpu cycles during updates). In other words, the sole reason for the restrictions seems to be to sell more Intel hardware.

>
>Regarding the row level locking issue, I have done system with hundreds
>of simulatneous users with page level locking and did not have any
>problems.

Its hard to claim actual problems will occur, unless you require top performance, in which case, monitors will show lots of unneeded waits, when transaction activity is high. OTOH, burning cpu cycles hardly matters when you've only got a few users.

>
>Also, if you are doing database replication, Sybase's replication server
>is light-years ahead of Oracle. I actually know companies that are
>strickly Oracle shops who use Sybase's replication server with their
>Oracle databases.
>

ORACLE's could use a lot of clean up, and certainly could become far more intuitive, but it is quite satisfactory with a little in-house competence. If you're talking about using ORACLE's SNAPSHOTs, rather than SR, then I can't disagree, because of the object naming limitations, and the trickiness that you sometimes have to engage in to cause multiple triggers on a condition to fire in the proper sequence.

>Because Sybase and Microsoft do not advertise their products in the same
>manner as Oracle, these differences are seldom mentioned.
>

No, you're right ... MS in particular concentrates on glitz, when at least a little bit of functionality in their product would be useful.

In addition, you've ignored some of the more useful capabilities, such as the Spacial Storage Option.
>have fun
>ray charb.
>

Bill Received on Fri Jun 28 1996 - 00:00:00 CEST