Good comments and I'll be sure this thread gets to the LINQ guys in Redmond.
Apologies on the acronym. I've heard so much about this over the last 6 months that I sometimes forget that lots of people haven't. I did link 😀 the
references in the article. This was hard to explain easily.
The developers know LINQ is 1.0. They admit that and say that there are places where things can really go horribly wrong. That concerns me for large scale projects, but how many projects are large scale? Most aren't.
One of the problems with views is that you need to then specify CRUD procs for updates to work well. There are some limitations with views, so I'm not sure how much help you get with them. Don't forget that if you give back 10-20% of a developer's time, then this doesn't help.
As far as performance tuning, they know it's an issue. Right now if something changes, I'd have to capture the SQL, go back to VCS, grab the old code, compile that and get it's SQL and then diff them. Not fun.
Or if I need to "tune" a set of code, I'd have to capture it, apply the tuning, wrap it in a proc, and then have the developer change the code to use the proc instead of using dynamic SQL. Again, not great.
However it's a balance. How much code will you need to tune? There could be lots of stuff sent through that doesn't need tuning or it doesn't matter. One nice thing is that the data doesn't get called from SQL Server until it's needed, so all those wasted queries, those calls developers make and then never use the results, go away.
There's also a consistency factor. The same code gets sent through, so none of the subtle differences you might get between two programmers or after a cut/paste/reformat that might cause multiple plans to go through, can go away. Some testing from the teams using workloads from applications showed that overall LINQ had better performance although there were places it was worse.
One problem that I saw last week is that the parameters sent through are based on the data. So if I sent through an update with "Steve" (nvarchar(5)) and then another with "Andy" (nvarchar(4)), I have two plans. That's bad. The parameter needs to match the data type.
I'm not sold on LINQ, but how many poor developers out there write applications for 5-20 people. They could save tons of time, get better overall performance even if a few queries are bad. Don't forget that lots of people don't have DBAs.
I'd like to see more examples of people using LINQ and then some analysis comparing this to regular code. Maybe even some LINQ v non-LINQ programming contests that could show people how LINQ can impact an application. Maybe a Contoso or IBuySpy app re-written with LINQ would be interesting.
It's a tool. It can be used well or not well, and I'd definitely be wary of scale issues, but it's not something to dismiss out of hand.