Application Server or Database Server?

In last week’s editorial, “SQLCLR: The Barbarian at the Gate,” I asked you to tell me why you are or aren’t using the SQLCLR and send me your opinions about why the SQLCLR isn’t used more in the SQL Server community. My request has generated some great reader feedback, and I’m looking forward to addressing many of the issues readers raised. But this week, I want to address one of the most common reasons that readers gave for not using the SQLCLR. These readers told me, basically, that they believe “Business logic belongs in the application tier, not in the database.’ I tend to agree with that sentiment, although I’ve learned to never say never (which, oddly enough, I think I just did).

Learn more from "CLR or Not CLR: Is That the Question?"

When I thought about avoiding mixing the database and application tiers in the broader context of “When should we use SQLCLR,” I came up with two provocative questions. First, when is a database not a database? And second, where does SQL Server the database start and SQL Server the application server end?”

Several weeks ago an interesting thread on the Solid Quality Learning email lists mentioned that one of our customers was positioning SQL Server as an “application server” rather than a database server for political reasons. The customer explained he was battling the “evil forces of oppression” that were attempting to keep SQL Server 2005 out of the corporate mix because SQL Server 2005 isn’t an “official” database standard for the organization. Readers who work for sane, rational companies might be surprised to learn that some IT shops may be dogmatically opposed to allowing the “non-approved” SQL Server 2005 database server platform in production but will allow SQL Server 2005 to be positioned as an “application server” that will host SQL Server services such as Reporting Services, Analysis Services, and SQL Server Integration Services (SSIS). I wonder where the line really is between the database server and the application server. Clearly, a substantial amount of what comes “in the box” when you buy SQL Server is unarguably a database server and always will be. However, a growing number of pieces that come in the box aren’t really core components of a database server, are they? Don’t get me wrong--pieces such as Reporting Services, Analysis Services, and SSIS are valuable pieces to have in the box. But they certainly do blur the line between database server and application server.

I’m sure people who say “Don’t put application code in the database” would accept the fact that you don’t need to physically distribute all the tiers in an application. So, is using the SQLCLR really putting application code in the database or is it simply putting a piece of the application tier on the same physical box as the data tier? Does it matter that both of the pieces might be running inside of the same physical process? Maybe. I’m not sure. If you’re arguing that yes, it does matter, are we simply being a bit dogmatic? All fun questions to argue about with your fellow database comrades. I do know that as SQL Server matures, the lines of where the database starts and stops get increasingly blurry.

A few years ago, when the availability of a database-like file system for Windows seemed more fact than fiction I joked that the next version of Windows should be codenamed “AS-400,” hearkening back to the days when it really was hard to see where the application and database stopped and started. Maybe I was wrong and SQL Server, not Windows, should be referred to as AS-400. We can still define where the database starts and ends in SQL Server today. But what about when Katmai ships? What about the release after that? In the future, will we simply have “Database Engine Services for SQL Server” on the same plane as the other services that make up the application server commonly called SQL Server?

See Brian Moran's follow-up article, "Great Minds Think Alike."