Sunday, August 21, 2005
21:16 | Posted by Sean McCown | Edit Post
There are several religious debates in databases.
One of the biggest debates is on platform. If I hear one more DBA scream that Oracle is vastly superior to SQL I think I'm going to start ripping out my eyebrow hair from inside my eyelids.
The simple truth is that with the exception of some the older crap out there like Faircom and Pervasive, every DB has merit in different situations. Is Oracle better than SQL Server? It really depends on what you're doing. Oracle is better at some things, but it isn't the right choice a lot of times. MySQL is better for some things, and it could actually win in some competitions.
First I'd like to talk about why there are mixed shops to begin with. To be perfectly honest, I'm not against mixed shops. I used to be a database purist, but I'm more pragmatic than I used to be. Mixed shops tend to happen in 1 of 2 ways. Either you get a VP in who is loyal to a vendor and insists that everything from here on out be done in their DB of choice, or you get a few 3rd party apps that only use a certain vendor as a backend, so you're stuck with managing a new database if you want that product. Unfortunately, it's that vendor loyalty that I'm talking about when I talk about DBs being a religion. So few tend to care about using the best tool for the job, they're usually more concerned with what makes them feel more macho for some reason.
Come on now... there's no reason to pick Oracle if all you're doing is putting together a simple website. And while Yukon is going to close the gap, Oracle has better HA features than SQL2K, so it would be a better choice if you needed some real 24/7 support. The same goes for XML. You wouldn't choose SQL2K over Oracle if you needed rich XML support. You also wouldn't choose MySQL if you needed rich stored procedure or transaction support, or really intense 24/7. You would choose MySQL however, if you were putting together a fairly simple app or website and just needed very quick response times to fairly large data sets. Some people swear by MySQL, I just don't happen to be one of them.
So mixed shops are ok, you just have to start putting more reasoning behind it. Go beyond that ridiculous loyalty you feel towards your favorite vendor because as we've found out with Quest, a vendor can turn on you without warning and the next thing you know you've got your entire shop full of their product and it's no longer doing the job for you.
It's really all just marketing anyway. In my experience most DBAs don't know enough about DBs to make a decision to begin with. Most SQL DBAs I talk to know so incredibly little about SQL, much less Oracle or MySQL or DB2. Their decisions are made purely off of marketing or basic familiarity. I can't count the number of times I've called Oracle support to have some brain-dead tech on the line make some stupid comment about SQL Server when they clearly don't have any idea what they're talking about. It's pathetic really.
The truth is that there are good reasons to go with pretty much any vendor, and you just have to find the right one. Those reasons aren't always technical either. Put simply, licensing can quite often be the deciding factor. And TCO is much more than licensing... it's extensibility, features, east of management, robustness, etc. Holding a lesser cost of not having to keep 5 different types of DBAs in-house is also included in TCO. These are all factors, so let's be blunt... you're not going to choose Oracle enterprise for your intranet when MySQL will do. Just the same you're not going to choose MySQL when you need to load a 4TB warehouse with millions of calculations. You're probably going to choose an Oracle and RAC solution. And for all the ground in between there are plenty of choices.
See, I know some people who are open source disciples and never waver from their freeware god, but when you get right down to it, none of the open source DBs have the same feature set the big 4 vendors have. They don't have any BI, and most of the time no real DTS capability, and monitoring is extremely limited. Not many vendors have monitoring solutions coded for MySQL so getting alerts based off of downtime and performance is more involved using an open source solution than a full-blown product. That's a simple fact of life. You often times get what you pay for, and this is one of those times that it's abundantly true.
TPC is Useless
If you look at everyone's latest TPCs you'll notice that they all reach incredible numbers of transactions/hr. The one thing they don't mention is that they not only reach these numbers with hardware configurations that almost nobody will ever get to work with, but with very few exceptions NOBODY has the transaction requirements that these products reach. That means that only the smallest percentage of companies worldwide will ever really tax any of the Big 4 with transactions. That also means that there is a lot of middle ground where any of them could easily play without any problem whatsoever. Yukon is going to make some major waves and Oracle's really going to feel it.
Over the years SQL Server DBAs have had to come to grips with the fact that Oracle actually is better at the higher end processing. Now, Oracle DBAs are having to come to grips with the fact that SQL Server is more cost effective. SQL Server is also really closing the gap in performance, which is another thing that Oracle DBAs are having to get used to.
So seriously... all you guys who turn this stuff into some kind of religious war just get off your high horse. Make intelligent decisions based off of the facts, not just your outdated opinions of what vendor is politically best.
- Sean McCown
- I am a Contributing Editor for InfoWorld Magazine, and a frequent contributor to SQLServerCentral.com as well as SSWUG.org. I live with my wife and 3 kids, and have practiced and taught Kenpo for 22yrs now.
- ► 2009 (53)