I recently attended SQLSaturday#2 in Tampa and had the brief chance to chat with David Hayden about LINQ (I suspect I am one of the passionate DBA's he mocks a little in that post!) and it really reinforced yet again for me how wide the chasm is between DBA and developer. For those who haven't ready my earlier post about Whats Wrong with Linq to SQL, I suggest starting there and then returning here.
So, here are some misc thoughts:
As a DBA I get paid to secure the data, to safeguard it and server resources, and to make it available for use as the business needs. I think too often DBA's focus on the first three and not the last one, and that's where many of the trade offs occur (and the chasm widens). We expect both too much and too little from developers, and we have to work on fixing that.
What does concern me more is that the same gap might exist in the depths of Microsoft. If you look at SQL 2005 you can see they've added forced parameterization to fix the problem where developers don't parameterize their statements and plan guides (useful on COTS, bandaid on in house stuff) and then we see LINQ to SQL which seems to de-emphasize stored procedures as well as the work MS has done in their patterns and practices library as far as packaging data access. Is MS prepared to recommend granting read/write access to tables as a standard (aka BEST) practice? DBA's are trying to secure and safeguard and stored procedures have been recognized for more than 10 years as the best way to do that (with the exceptions for search noted above).
As a pragmatic DBA I'm more than willing to compromise at the enterprise level. Many of my clients use dynamic sql with parameters, it works fine, and no profit for them in changing things for the sake of change. As someone interested in industry trends I want to make sure that we (DBA, Developer, MS) share a common vision of best practices and when it's ok to diverge from them.
Finally, I'll just that if you've never worked as a DBA and a developer I highly recommend spending 60 days in the other persons shoes. Both jobs are challenging and absorbing, and understanding the pain of the other side can go a long way towards building a productive relationship.