The Dutch .NET usergroup held its session at Integer yesterday. Marcel Peereboom was the host and held an interesting session on the new features of SQL Server 2005. It's a difficult task to be comprehensive as the featureset is so big. Most time was spend on features that affect the developer. The rhetorical question was raised what to develop in T-SQL and where to use C# (or other available languages that target the CLR). As T-SQL is set-based, most of the time that's obvious. Let the database-queries be done by the one that's most efficient at this task.
Nevertheless, I was, and still am, a bit puzzled by what Microsoft tries to accomplish by introducing a new queuing mechanism that's hosted in Sql Server. I'm talking about the SQL Server 2005 Service Broker. Why would I want to do message queuing in T-SQL? Can you still call this T-SQL? And the link here points to an article that has a tagline mentioning SQL Server applications. To me, the database is a storage container. And an efficient one at that. Stuff gets put in, and you get stuff out. Okay, this sounds very much like queuing. However, I feel much more comfortable using (reusable) classes, when devising a queuing mechanism. What would happen to the SQL-code when business logic is getting more complex? Oh sure, you can put business logic in stored procedures written in C#. How's that for maintainability! Some logic here, some logic there. And when the application blows up, you'd better have a solid tracing mechanism to figure out what went wrong.
Anyway, for anyone interested in how much SQL Server 2005 is going to cost, Microsoft just announced that.