Re: SQL Server, Oracle or Informix

[This is in response to Daniel Paz's original post, not Mike Krilewski's response, but I don't have access to the original.]

    This is probably going to get me in trouble on this list, but here I go...

    I used Oracle 7.3 as a database administrator extensively 5 years ago, then had a stint with Sybase, then extensive experience with SQL Server 6.5 and 7.0, and now I am back on a project working with Oracle 8.1.6. I have similarly, as a programmer, dealt extensively with programming under Solaris, NEXTSTEP (BSD Unix w/Mach kernel), OpenStep under NT, Visual Basic/COM+/ASP under Windows 2000, and now Java on NT and Solaris. In other words, I have been deeply involved on both sides of the great database and technology divides in the programming community, with Microsoft technologies
(COM, VB, VC++, ASP, SQL Server) on one side and a mix of open and
proprietary technologies (*nix, J2EE, Oracle) on the other.

    I have witnessed and formerly been a part of huge amounts of anti-Microsoft bigotry from those on the "open" (and OO) technologies side, but, having been to the "dark" side, I can confidently say that most if it is highly unfounded and blind. These comp.databases.oracle.* mailing lists are rife with pithy statements about alleged instability of Windows NT or SQL Server that just aren't true, or, at least, are no longer true, particularly with Windows 2000 and SQL Server 2000.

    The history of these two platforms can briefly be summarized as follows. Microsoft has always primarily emphasized ease of use, programmer and DBA productivity, developer support, and affordability, all "out of the box". The *nix/Oracle side has primiarily emphasized scalability, stability, scriptability (i.e., everything must be able to be done from a command line), and raw performance. As a result, each side seriously lagged the other in the other's areas of strength.

    In the last few years though, since about the releases NT SP4, Visual Studio 6, and SQL Server 7 , Microsoft has gained *serious* ground in scalability, stability, and performance. Now, with Windows 2000 and SQL Server 2000, an objective observer would probably conclude that Microsoft is the match of *nix/Oracle in those areas for all but the most high-end demanding jobs.

    The *nix/J2EE/Oracle world, however, is still way behind in ease of use, programmer and DBA productivity, and affordability. And though there are many resources on the Internet for *nix/J2EE/Oracle programmers, there is nothing as clean, comprehensive, and accessible as the MSDN program.

    So, let's get to the Oracle 8.1.x vs. SQL Server 2000 specifics. Here is my suggested decision tree for choosing a platform:

1. If you cannot use Windows 2000 as your database server operating system, choose Oracle.
2. If a built-in feature of Oracle (spatial data, in your case) is highly critical and has no corrolary in SQL Server 2000, choose Oracle. Take a good look at resources and extensions from Microsoft and third-parties, as well as properly evaluating the Oracle feature, before making this decision. There's lots of support out there for SQL Server.
3. If you have an extremely large database or the need for a water-walking database, choose Oracle (and get ready to pay a lot to acheive your goals).
4. If you are perversely interested in using the full Oracle product line
   (application server, portal server, LDAP server, etc.) for your project,
   choose Oracle.
5. If you already have a stellar Oracle DBA as an employee or hired as a consultant, *maybe* choose Oracle.
6. In all other cases, choose SQL Server.

    Here's why SQL Server should be the default choice in all other situations:

1. It is *hugely* less expensive than Oracle. Oracle is generally at least $20K per CPU, and often closer to $30K per CPU, just for the basic database. They try to get major money out of you for most options on top of that. SQL Server 7, on the other hand, has until recently been available for $8000 per server (not CPU; you can load as many CPUs as you want on the server), with unlimited connections originating from the Web. I believe SQL Server 2000's pricing has moved towards a per-CPU pricing structure, but it's probably still much less expensive than Oracle.
2. SQL Server is *way* easier to manage. It installs in 5 minutes and is immediately accessible to anyone with a reasonable amount of progamming and/or SQL knowledge. Oracle is more difficult to install (and 8.1.7 just plain doesn't seem to work under Windows; we had to stick with 8.1.6 for now), and it's administration tools are absolute cr*p! Fortunately, there are some good shareware tools that are far superior to Oracle's tools to fill some of the gap (I can't imagine that any serious DBA uses Oracle's tools), but you will immediately find yourself needing to worry about init.ora parameters, spreading database files across disks, and struggling with Net8 setup on machines.

    Oracle is a DBA Consultant's dream database. It's got the market share and conventional wisdom reputation on its side to get companies to keep buying it, yet it requires DBA's with deep experience with it to make it work well. Such DBA's often become independent consultants, because there's big money to be made doing so.

3) SQL Server is very easy for each developer to install on his/her own machine without hogging resources, generally increasing their productivity if they work close to the database layer at all.

4) SQL Server "just works" much sooner and much longer before needing attention for performance tuning. On my last major project, we *never* spent time specifically profiling or tuning the performance of SQL Server. There was no need, because it was simply fast enough out of the box with common sense indices in place.

In contrast, I just spent days trying to find out why our Oracle database performs 2-3 times more slowly than our SQL Server database on our smoke tests. Even with its files spread over 4 disks on two different UltraSCSI controllers and its init.ora parameters seriously bumped up so that all the memory on the machine was devoted to Oracle, it was getting the pants beat off of it by a SQL Server 7 database running with its database files all on one disk. It turns out that Oracle takes a heck of a lot longer to parse and build query plans for dynamic SQL queries than SQL Server does. We will probably shift many of our queries to stored procedures to try to boost Oracles performance to become comparable with SQL Servers (which will itself be boosted by using stored procedures, no doubt). [PLEASE, if anyone feels the need to dispute the points in this paragraph, please do so in a post that I will be sending shortly after this one.]

5) SQL Server 2000 has automatic, dynamic optimization that is probably worth a serious look. Oracle desperately needs the ability to automatically fiddle with its own init.ora parameters in response to database activity. It's remarkable how much you have to read just to get to a good baseline configuration of Oracle, much less a near-optimal configuration.

    So, to sum up all of the above for your situation, I think it comes down to this: Only if the spatial data capabilities of Oracle are perfectly suited to your GIS needs and only if they have no adequate counterpart in SQL Server world (and I would check with a Microsoft sales rep and some SQL Server newsgroups before concluding this), get Oracle. Otherwise, for a 13G database, which is smallish these days, that is not prohibited from running on Windows 2000, definitely choose Windows 2000 Server (or Advanced Server, if you're going to setup a failover cluster) and SQL Server 2000.

Patrick Rusk Received on Tue Jan 30 2001 - 23:18:04 CST