Re: Differences between Oracle RDBMS and MS SQL Server

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. Received on Wed Dec 06 2000 - 16:38:39 CST