Opinion of use of LINQ

Question

Opinion of use of LINQ

Viewing 4 posts - 16 through 18 (of 18 total)

You must be logged in to reply to this topic. Login to reply

Welsh Corgi SSC Guru Points: 116520 More actions · Answer 1

Sean Lange (4/4/2014)
OCTom (4/4/2014)
This is my take on LINQ to SQL. I have found that it does not handle large data sets well. It can be slow. And, because you do not have the SQL code, you can't tell what is causing the problem. I use LINQ on small datasets. If I need to traverse large datasets, I may still use LINQ, but, I will use a stored procedure that has been proven to be efficient. By large I mean about 100,000 records or more in a single query. Where I work, most dataset are well below that. I have one project I'm completing where I am not using LINQ to SQL at all.
LINQ should not be banned, but, experience tells me that it has its place. I now recognize whent to use it and when to not use it at my shop. Of course, you may have different results.
Tom
It's fir day today... :w00t:
One of the other developers here knew that I am pretty savvy with sql so he asked me to help him debug a query that was created with EntityFrameworks. OK, I know the topic here is LINQ but it kind of the same thing. Anyway, he sends me the query and it was over 10k lines in SSMS and had somewhere on the order of 100 or so subselects in it. He didn't quite understand why I told him I couldn't debug it without some frame of reference. He wasn't really sure what the query was supposed to do. Needless to say I handed it back to him untouched and told him we could look at when he could tell me what it does. He is no longer here and I never heard or seen that monstrosity again.

Hmmm interesting.

🙂

For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/

Jeff Moden SSC Guru Points: 1004441 More actions · Answer 2

One of the biggest problems I've had with Linq to SQL (and other ORMs, as well) is the data-type mismatching it sometimes does. Most of our character based columns are VARCHAR but Linq to SQL sometimes fails to realize that and passes NVARCHAR literals to be found. That makes the code Non-SARGable (basically, can never do an Index Seek) because, due to data-type precedence, it causes the entire table to be scanned so it can implicitly convert the entire column to NVARCHAR to do a lookup.

Once I told the Developers about the problem, they've taken steps to use the correct data-types. I just don't know what those steps are but I'm sure that my assistant DBA (Google) could find the steps for you. 🙂

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

andrew gothard SSChampion Points: 12315 More actions · Answer 3

Welsh Corgi (4/4/2014)

I do not like triggers either. Since it only fired when an abject was created, Dropped or modified it was not firing off that much. But now I know better.

I had an issue with a consulting firm dropping objects and blaming it us.

When they cried wolf I showed them that they were doing the dropping.

They are gone now and no more issues.

Thanks.:-)[/quote

That's the problem with Abject Oriented Programming (I'll get my coat)

I'm a DBA.
I'm not paid to solve problems. I'm paid to prevent them.

Aditya Daruka Old Hand Points: 339 More actions · Answer 4

Hello all,

I moved into data warehouse after being a hard core c# developer for multiple years. My take on LinQ to SQL is as below.

1. Nothing should be banned. Everything is there for a reason and adds heaps value if used appropriately.

2. LinQ to SQL is great for small data sets.

3. It is not advisable for complex sql joins as it generates sql every time and executes raw sql statements on db server there by re-generating execution plan every time, etc.

4. It is very hard to keep track of what has been changed by developers in the code layer which might affect db performance.

5. It makes further enhancements around that area/section hard as now things would require changes to code and sql both. Any changes to code layer would require, release which is normally more time consuming and tricky compared to releasing sql server objects.

There could be many more reasons to avoid it if it is possible. I kind of like to keep data specific codes encapsulated within stored procedures for maintenance reasons.

Hope it helps.

Aditya Daruka