One of the things that I noticed while at the PASS summit is that we can now clearly see two opposing trends in the way SQL Server is being used in applications. On the one hand we have the dumb database brigade. They regard SQL Server as simply a 'data dump'. The real data model is held in, and all the work is done in, the middle tier, using Entity Framework, nHibernate, or their ilk. SQL Server's job is simply to respond in a timely fashion to any dynamic SQL requests that are fired at it.

On the other hand, we have the group who view SQL Server as a powerful enough platform in it own right, for all but the most extreme applications. They would rather dispense with a .NET-based object layer completely, placing all the business logic in SQL Server and serving up the data via wafer-thin front-end applications, using Web Services.

Both groups are viewed by the community as being at the "wild fringes" of SQL Server development and neither receives whole-hearted approval. Can one reconcile these two opposing trends? I hope so. I admire what .NET developers can achieve with their platform, but also know that SQL Server is far too powerful to be used as just a "data dump".

Either type of use may be appropriate for given circumstance; neither is a universal panacea. Far more damaging than the occasional excesses of the "wild men" on the fringes, is the tedious orthodoxy that states that 'you should never do that in SQL Server', or 'that should always be done in the database'.

I am wary of this sort of "best practice" advice. It is usually a device to surreptitiously hide irrational dogma, or else just a vapid reflection of "what Microsoft says". It's the sort of received wisdom that can stifle creativity and innovation.

Anyone who wishes to create an application on an "unorthodox" platform needs to first prove that it will be as secure, scalable, deployable and maintainable as the "orthodox" alternative, and that it will perform as well and take less time to develop. Once that battle is won then it becomes a reasonable platform to develop on.

SQL Server is now versatile enough to accommodate all sorts of methodologies and architectures. Although the over-stretched DBA will occasionally curse the introduction of 'foreign' concepts, such as XQuery, the result is that SQL Server has positioned itself to be uniquely adaptable to new thinking about the way that applications are developed.

And that is something from which all of us will benefit.

Cheers,

Tony (Guest editor, while Steve takes a well-earned Thanksgiving break)