The problem of moving from SQL to LINQ

A left (outer) join B on A.bid=b.id

The above sentence is called a left connection because the left (join, connect) is translated to the left, so this is a translation of the keyword in the grammar, not the principle of the connection, which cannot be thought to be connected to the left of the first table. Instead, it is connected from the right side of table A. The reason is simple, such as a common query: Select T.id TID from table1 T. The back of the T is a mark on the Table1, and then look at Tid it is also the mark of t.id, what their function is we do not say, at least we know that the syntax of SQL is to add additional parameters or description of the post. So I look at the above left JOIN statement, I know left and join fart relationship does not. The statement should be divided into: Select A.* from A left join B on A.bid=b.id. Outer didn't write because all of the left join is the outer join,right join analogy! Back to the syntax we just had, the red section represents the operation of the entire statement and the qualifying keyword, and left is a post-attached message, which means that a is placed on the left-hand side, and similarly, if you replace left with right it becomes a on the right-hand side, and if the outer is added to the back, Outer and join pairs are a pair, the two of them correspond to the inner join, which is understandable, because the inner join discards all the empty records from the two tables, so you don't need which one is left or right, so, a table behind it is omitted, Directly is a inner join B on. Anyway, why do you want to divide the left? Very simple, we like to draw the table from left to right, set on the left, and then draw the right, that is, first to the left of the table to find out, and then the right to take out the above to fight, how much to spell how much.

"Left and right inner joins in LINQ"

The second line above, I'm Gray, is the right join I found on the Internet. The reason is black, because I think it is not right, it is actually a left connection, but the left and the two tables in order to change it. I never found a LINQ statement to implement right join. And as I keep looking, I get more and more exposed to the notion that LINQ is not SQL-independent. Of course, it doesn't mean that LINQ is not related to SQL, on the contrary, they have a very big relationship, but if we want to be in LINQ all the time with the idea of SQL, it can lead to results that we don't want to see, such as some simple jobs that we can complicate or even solve. Because we are not facing the "table" but "to the image."

So, I put aside the idea of looking for left and right joins and LINQ, and thought of myself as a new person who would not be SQL, to learn LINQ. And just as I was learning LINQ, I found that there were many things in the SQL that were not in LINQ, and these things are usually directly accessible by complex joins that we can bypass in SQL.

More Wonderful content: http://www.bianceng.cnhttp://www.bianceng.cn/database/SQLServer/

And I've found that joins in LINQ are nothing like joins in SQL, or that they are not related to each other, a bit of a sense of C and C + +.

In this way, we must have a new idea, to find this new idea, we need to first look at why we are looking for LINQ and SQL relationship.

{Query data requirements}--->{The SQL statement that we would have written in SQL--->{LINQ} that matches the SQL statement

See, we know that there is no tutorial on SQL Transfer LINQ, LINQ to SQL Microsoft also did not explicitly give the algorithm, we have to torture ourselves, why bother?

Then we take back the heart that we think we are, and change our ways:

{Query data requirements}--->{to resolve requirements LINQ}

In this case, we will only encounter two ethnic problems: one, LINQ can not achieve our needs; second, efficiency issues. Let's look at them first. The first one, I think the problem is not small, after all, is a language, language is consistent with the specifications of the language, without its completion of the demand, only it can not take into account the second person problem. The second question, the efficiency issue, is really a big problem, because if you write LINQ in Hot blood, you can totally assume that your LINQ is extremely inefficient and I've seen a LINQ statement with dozens of methods in it. LINQ, like SQL, is a language that needs to be constructed, so before we write, we have to have a deep understanding and learning of LINQ, just as we were learning about SQL, and looking at a SQL can perform its approximate execution complexity. Well, our problem comes out, is to learn linq!

I have also learned before LINQ, but also useful, but, at that time too young, a 杦, now, shame and then Yong, to learn.