Grant, I disagree that removing a tier saves time. Tiers are there for a reason! But we can agree to disagree. Bob, good for you for spanking Steve on the acronym!

I've blogged a bit about LINQ to SQL and in my view it's a tool developed without talking to a DBA. Here's a quick rollup of my objections:

- It allows stored procedures (except for selects) but does nothing to encourage their use

- It requires table access or the table value function hack. Do we as DBAs' believe that the coding gains are worth allowing table level access in our apps?

- There is no easy way for the DBA to understand what has changed in data access. We should all understand that even the most minor change can affect performance, the most common example is adding a column that eliminates the effectiveness of a covering index

- When a performance problem occurs the best we can is try to intervene with a plan guide, otherwise its a recompile of the app (or at least the data access dll)

I think - and could be wrong - that it's less about time saved than the many developers just don't get/don't like data access. Most data access is vanilla and just not that hard to write/change when needed, but it does require a little knowledge (tools can generate most procs).

I'll also add that in many cases it's us - the DBA's - that have caused our own pain, making use and changing of the database so painful that developers will eagerly do an end run around us.

It's easy for this to turn into DBA vs developer, ala the great CLR debate. I think it's an opportunity for a hugely useful discussion about how we do data access and why, and perhaps it will be us that modifies our stance?