CODEWITHSUNDEEP
c#entity-frameworklinqstored-proceduresperformance-testing
Hemi81
Hemi81

Reputation: 588

LINQs Joins vs Stored Procedures Joins

I read this article on using LINQs for doing Joins. I was wondering how much benefit this would be aside from writing a stored procedure that would join the tables? Would it cause any kind of performance issues using joins with LINQ?

UPDATE:

So using this as an example:

var employeeInfo =
                from employee in employees
                join addInfo in additionalInfo on employee.ID equals addInfo.CategoryID into allInfo
                select new { CategoryName = category.Name, Products = allInfo};

Would this simple join benefit me as apposed to a stored procedure? I know depending on the size of the tables and number of tables you may want to join could make a big difference on when to use LINQ vs store procedure. What would be a good "rule of thumb" on the number of tables and sizes one should use for LINQ joins and when performing LINQ joins becomes too much of a performance hit?

Upvotes: 2

Views: 1049

Answers (1)

Mike
Mike

Reputation: 449

The performance of queries joins in general depends on if the proper indexes exist on the joined fields. If your query is producing a full table scan, fields aren't property indexed your performance will be directly impacted. Perform an explain plan if you're concerned about stored procedure performance.

As to LINQ and joins, you don't want to do it.

Here is a good article below on LINQ joins, from the article:

One of the greatest benefits of LINQ to SQL and LINQ to Entities is navigation properties that allows queries across several tables, without the need to use explicit joins. Unfortunately LINQ queries are often written as a direct translation of a SQL query, without taking advantage of the richer features offered by LINQ to SQL and LINQ to Entities.

https://coding.abel.nu/2012/06/dont-use-linqs-join-navigate/

Upvotes: 1

Related Questions