I must add that we generally starts with a problem, then have to find a
solution, in terms of writing in SQL or in LINQ code. Translation from SQL
to LINQ is a little bit artificial. As example, the problem is NOT about to
translate:

SELECT a.workerID
FROM workersSkills AS a INNER JOIN requiredSkills AS b
   ON a.skillID=b.skillID
GROUP BY a.workerID
HAVING COUNT(*) = (SELECT COUNT(*) FROM requiredSkills)

into LINQ, but to find the workers having all the required skills. I
STRONGLY suspect someone using LINQ will come with some "for each worker",
get a list of his skills, loop through the required skills list, to see it
they are all contains in the list of skills for the actual worker we just
got, and if so, keep the workerID in a 'result list'.  So, yes, that
procedure will be easier to follow, but how many people will need to
'follow' it once it is working? And, it seems to me, the LINQ solution will
be based on simple SQL statements, rather than on ONE, more complex,
statement, but as far as the whole problem has to be solved, the LINQ
solution would be clearly more verbose, because LINQ does not 'lead'
culturally to solve a problem in 'one step' ?

Note that I don't say in any way that SQL is a simple language. You don't
come naturally with the solution above first hour you learn SQL, unless you
are really a genius. But as time passes, you see the 'patterns' as naturally
as a 'for each' loop.

By the way, another great advantage to LINQ: it allows you to write a query
against a database where, in theory, you can be forbidden to write any query
(by some administrative politic).

Vanderghast, Access MVP

Well, due to the complexity of the query you wish to perform. Don't
forget that LINQ doesn't just target SQL.

I don't know why you'd think LINQ would be inappropriate for complex
queries. If the complexity has to be *somewhere*, I'm happy for it to
be in C# personally.

Well, in some cases a view or stored proc could make sense - but given
that the complexity has to be somewhere, it may well be just as
sensible to do it in the LINQ layer as anywhere else.

    Don't buy the 'it's a v1 product' excuse! It's not a v1 product, it's
taken them a couple of previous attempts to get this far, so I don't
see how this can be a v1 product. Then again, there are enough examples
out there which prove that it can be done without a lot of hassle so
why they didn't implement it is beyond me.

    every nested set is a query on its own. You can obtain a correlation
filter in the nested set and use that with an EXISTS query or IN query
on the parent set :) This limits the nested set on the rows related to
parents you've fetched. You can then either build an in-memoryh lambda
to compare rows or build 2 hash sets and compare hashes.

    What's odd is that this is the way you have to do eager loading
anyway, so they have written the code already. At least, more or less
(as their eager loading code isn't up to par)

    I don't know about the nested sets in projections, probably not. They
do have an '.Include()' extension method if I'm not mistaken which
allows you to specify related entities to fetch inside the query, using
eager loading. I'm not sure how they'll do that though (i.e. with the
same approach as linq to sql or with a better approach).

        FB