Re: Differences between Oracle RDBMS and MS SQL Server

In our last gripping episode lindawie_at_my-deja.com wrote:
>
>
> Oracle and SQL Server are very different products so a direct
> comparison of feature sets may not be terribly useful. From the
> discussion thread so far, it is apparent that in some cases statements
> about the "opposing" product are based on misconceptions or outdated
> information. True, Oracle 8i is superior to SQL Server 6.0, just as
> SQL Server 2000 is superior to Oracle 6. If you are making
> comparisons, you must look at the latest releases of both products.
>
> For just about everything available in one product, there is
 equivalent
> functionality in the other product. The resulting code may look quite
> different, but the functionality is there. In one case we might use
 an
> operator, and in the other case we may need to call a function. So
> what. Code is code, and making such low-level comparisons is
 technical
> nitpicking. The same applies to administration. Both products allow
> you to do whatever you need to do. The details of how it gets done
 are
> not so important. And both products are both robust, scalable and
> deliver good performance.
>
> Off the top of my head, I can only think of a few examples of highly
> desirable, frequently used features that are present in one product
 and
> not in the other. For example, Oracle packages and CONNECT BY for
 tree
> processing. SQL Server bulk copy processing in all of its
 incarnations
> (bcp.exe, bulk insert statement, DTS, API functions) is unbeatable for
> speed and simplicity. ANSI join syntax and the ability to return a
> result set from a stored procedure just by writing a select statement
> are among my favorite features.
>
> Of course, the comparative feature "scorecard" changes with each
> product release, so any perceived technical shortcomings will probably
> be irrelevant in a year or two.
>
> From a technical perspective, the main difference I see between the
 two
> products is how one needs to go about designing a data model and
> application to create robust, high-performance, scalable software
> products. I am talking here about enterprise transaction systems,
 busy
> web commerce sites, large data warehouses, not modest departmental
> applications. There are plenty of examples of such systems in
> production on both platforms, so we know it is possible.
>
> From my limited Oracle experience, all of the successful applications
> that I have seen had denormalized data models and stateful designs
 that
> relied heavily on ISAM-style processing, that is, single row
 processing
> using cursors. This type of design is a blueprint for failure on the
> SQL Server platform. Successful transaction systems for SQL Server
 are
> stateless, have a normalized data model and use set operations for
 just
> about everything. Cursors are rarely, if ever, used. Row-level
> locking is turned off.
>
> These two architectures require developers with different skill sets
 to
> implement them successfully. If your development team is accustomed
 to
> writing procedural code and this is what they know how to do, they
 will
> probably be more comfortable with Oracle. If, on the other hand, your
> developers know and like a declarative language and have the
> demonstrated skills to write efficient ten- or twenty-table joins
> against large tables, then they should be using SQL Server. It would
> be a waste of their talents to be writing lots of procedural code.
>
> However, in the final analysis, there is only one factor that really
> matters, and this is total cost of ownership (TCO), so any discussion
> of Oracle vs. SQL Server must address this issue. TCO is not just the
> initial purchase price, it encompasses all operating costs, including
> personnel, for the life of the installation. There is no getting
> around it, Oracle is very expensive to buy and operate. It may be a
> good product, but for most organizations it is a poor value.
>
> The cost and availability of personnel is a critical aspect of TCO, at
> least where I live (Seattle, WA). Top notch SQL Server developers are
> expensive and hard to come by. It is virtually impossible to find
> really good Oracle people, and they are even more expensive. A great
> database product is of no use to me if I cannot find qualified people
> to staff projects.
>
> Slick technical features are nice, but in the end they will not sway
 an
> informed management. Executives will base their purchase decisions on
> things like how much of the budget will this consume, how can they
> justify paying developers and DBAs twice as much as nontechnical
> people, or is it more cost-effective to just go to an application
> service provider.
>
> Linda
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>

Well said.

--
David Fitzjarrell
Oracle Certified DBA


Sent via Deja.com http://www.deja.com/
Before you buy.