Anders Pedersen (4/22/2008)

---

Horrible idea in my opinion.

Who cares if a developer saves 10%-20% (the numbers I have heard bandied aroud) by using LINQ during development time? How much time in man hours, is an application under development, versus being used as a production application? Doesn't it stand to reason that making the queries efficient is more important than saving the developer a bit of time?

With LINQ how am I as a DBA suppose to track down a performance problem? We all know that whenever there is a performance issue with an application, the database is the first to be blamed and we are the first to have to investigate to prove it is not the database before the application developers jump on the app code.

With LINQ queries against SQL could come from anywhere. With zero control from the DBA on how the data is accessed (and not even speaking about security issues, just the queries themselves).

I took over this position about a year and a half ago. I had a trace running on the server to capture all stored procedure and function calls for a total of a year... (yes a bit of an overkill). I took samples of the data at 3 month intervals and worked on the queries that took up the most cummulative time on the server. By very easily being able to look at the stored procedures, I optimezed the worst 3 to take less than 5% of the original time to run, the worst one I cut down to run in 1/1000th of the time. How would I be able to do that with LINQ?

Sorry, I fail completely to see why LINQ should be compelling to any organization. I can see why it would be to front end developers, but as a DBA I will fight against the use of LINQ in any organization I work in. Unless I can be proved wrong (same view I had on CLR, and I have been proven partially wrong about the CLR).