Beware of hidden assumptions in software development projects

I’m going to pick on one thing (and a surprising thing at that), but the one thing isn’t really the point.

I’m working on a project in which the backing database store is being moved from SQL Server to Oracle.  The reasons for why this move is being made is interesting in itself, but I’m not going to talk about it here.

To give a little background, I am a certified SQL Server DBA.  At a Master level, even.  I’m not sure why (well, I know why, I took the exam), as when I consider myself against really great SQL Server DBAs that I know personally, I’m not at their level.  But, okay.

During the great days of 2000, I went through a huge undertaking to prove that SQL Server could scale, as our venture capitalists were Oracle people.  The details of that are also interesting, but I’m not going to get into that here.  Needless to say, we proved it for what we needed at the time.

Fast forward to the current project, and let me ask a simple question: has anyone ever questioned or doubted whether transitioning from SQL Server to Oracle would hurt either performance (in terms of throughput) or scalability?

I’ll go ahead and answer that question: no.  Considered in the abstract, the idea that you could possibly have scalability or performance problems when moving from SQL Server to Oracle was not only not on the radar for anyone involved in the project, but seems beyond the pale.  *Of course* Oracle can meet or beat SQL Server.

And yet, we found a reproducible case of SQL Server out-performing Oracle by a factor of over 50 to 1.  There was much angst, and the usual random suggestions (grasping at straws) that somehow our .NET code calling SQL Server was magically faster than the same code calling Oracle.  Then we reproduced the lower performance using Java hitting Oracle.

In the long run, it looks like the issues will be addressed by our engaging with Oracle DBAs, and I honestly and truly don’t give a shit about having a debate about Oracle vs. SQL Server vs. .NET vs. Java vs. blah blah blah blah.  And I really don’t care about NoSQL here.

But the fact remains that we simply assumed (rationally, I would say, given what we knew and what seems to be common knowledge) an outcome, and then had to scramble when the outcome didn’t match what we assumed.

Track these assumptions and validate them.

posted on Monday, February 07, 2011 8:28 PM Print
# re: Beware of hidden assumptions in software development projects
2/8/2011 7:27 AM
Over the years I've worked on projects with Ingres, SQL Server, Informix, Oracle, and DB2. SQL Server has always performed the best of this bunch, at least on any hardware to which I've had access. Memorable in particular is the wisdom of Oracle zealots on one project who forbid JOINS as too costly, and not a "best practice". If you can't JOIN efficiently, then what's the point of SQL?

Each product leads you to a different design from the bottom up, which isn't limited to databases. Witness performance problems from Java code ported to C#, Unix-compatible C++ ported to Windows, etc.
# re: Beware of hidden assumptions in software development projects
2/9/2011 9:38 PM
Like I said, I don't want to get into the whole Oracle vs. SQL Server performance thing. I've always been happy with SQL Server performance obviously. I've recently had to deal with debating people about whether or not you should use stored procedures, so those discussions usually blow.

Further investigation suggests the root cause of the issue is SAN related, which actually makes a lot of sense to me.

Post Comment

Title *
Name *
Comment *  
Please add 7 and 6 and type the answer here: