I heard someone state that LINQ (see
http://www.sqlmag.com/Article/ArticleID/48759/sql_server_48759.html for details on LINQ) was going to rescue developers from having to know TSQL. Well if that's true then who will rescue us from LINQ? LINQ like so many other technologies that have come about makes certain things easier by abstracting the underlying objects or code and providing a "simpler" interface. That sounds great but as we have learned over and over again this comes at a price. The price here will ultimately be performance in the database. LINQ will allow you to write an English like statement that will be translated into TSQL and sent to the database as essentially an adhoc sql statement. So again instead of steering developers towards writing efficient and reusable stored procedures we give them the exact opposite. We will end up with code that has little chance of being optimized properly and few chances of getting plan reuse. As a consultant specializing in scalability and performance I can tell you that the number one culprit out there in this regard is exactly these types of applications. Ones in which the developers are coerced or even forced into using adhoc code due to time constraints or technologies such as LINQ. Now don't get me wrong I am not blaming these issues on developers, I used to be one:). They just happen to be the ones creating the code for the database these days. Most DBA's if they had their way would prefer to use stored procedures first. Only time will tell but I expect my job as a performance consultant to heat up in the future once everyone starts using LINQ. You see most large apps started out small and performance isn't as much of an issue then. But they tend to grow very large these days and adhoc sql and poorly optimized queries just don't cut it in the long run. I hope to be proven wrong but history leads me to believe otherwise. Any way happy coding...