Oracle versus SQL Server in the Enterprise
- I'd Like to Help, But...
- What Concerns Me Is...
- Oracle Will Make You Thinner and Better Looking?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
As an Oracle DBA in an organization replete with SQL Server installations, I find myself receiving comments or questions on a regular basis regarding differences in the two products. The vast majority of comments I receive fall into one of two camps.
The first of these questions or comments usually come out as "Can you teach me Oracle?" My polite answer is generally "Sure, I'm actually just about to do a class on that; I'll call you when it's ready." This is a way of being nice without committing to what the questioner doesn't realize could be weeks of effort on my part, not to mention theirs. (Of course, I'm not so much concerned with theirs because their efforts don't generally keep me at the office later than I need to be.) Sometimes I'll take the extra step of telling them where they can download a full version of Oracle to install and play with. But sometimes that would be a bad thing for me to do because it might only invite a plethora of follow-ups.
The second type of question I get is something like this: "We're having this issue with SQL Server, and I want to see how Oracle handles it." Okay, now we're getting somewhere. I can offer some assistance, but this won't be a request for hours upon hours of my time. It will be a well-thought-out description of a specific problem, the Oracle answer to which will guide the questioner down a road that might lead them to a solution to their SQL Server problem. The questioner continues: "Our SQL Server databases are getting too big—how does Oracle handle this?" Sigh...I stand corrected.
I'd Like to Help, But...
Maybe my approach has been wrong all along. Maybe I should just write down a summary of what the likely concerns might be. Then I could hand this list to each person who comes calling for advice. If the individual is on a crusade for general Oracle enlightenment, this list will be a somewhat comprehensive—albeit technically light—spiritual guidebook of sorts. If, on the other hand, the inquisitor is seeking resolution of a specific and quantifiable concern, this paper will serve to guide them in the right direction so they can find the answers they're looking for from their own desk.
But no, that would all take too much time. And as much as I want to help these sojourners, I don't really care to go too far out of my way for them. That would set a bad precedent. That would encourage them to come back to me yet another time with yet another vexation. So let me instead just take a few minutes to ramble about what I shall call design flaws in SQL Server. Architectural concerns that cannot be worked around. Axiomatic principles, if you will, that often do not get raised when diving deep in the technical details of a database platform decision. Rather, they must be lived with if your decision has been to use Microsoft's database platform. Features, or lack thereof, can often be worked around, but a product's basic machinations cannot be altered easily—certainly not by an end user of closed source software. Oh sure, there are ways to make the pains not hurt as bad as they might, but they cannot be overcome. Therein lie many of the differences between the two platforms, not to mention the source of many ills.
Bear in mind, I'm not working on a system for the florist down the street. No, Microsoft is making its best attempts to push itself into the Enterprise. Into Oracle's neighborhood. So that is what I am about to discuss: issues of concern to enterprise systems managers.