A left (outer) join B on A.bid=B.id
上面這句話叫做左連接，原因是left(左)join（加入，連入）被譯為左連接，所以，這是關於語法中關鍵字的翻譯，而非連接原理，造成不能以為是從第一張表的左邊連接。相反，它是從A表的右邊開始連接的。原因很簡單，比如一個普通的查詢語句：select t.id TID from table1 t。後面的那個t是對table1的標記，再看TID它也是對t.id的標記，它們的功能是什麼我們暫且不說，起碼我們知道了sql的語法習慣是將附加的參數或者說明後置。這樣我就再看上面的左連語句，就知道了left和join屁關系沒有。語句的劃分應該是：select A.* from A left join B on A.bid=B.id。outer沒寫，是因為所有的left join都是left outer join，right join類推！回到我們剛剛的那個語法，紅色的部分代表了整個語句的操作及限定關鍵字，而left則是A的後置附加信息，它的意思是說，A是放在左邊的，同樣，你若把left換成Right就成了A放在右邊，而如果後面加了Outer了呢，outer和join對是一對，他倆與inner join相對應，這下就好理解了，因為inner join將兩張表裡面所有的為空的記錄都棄掉，所以，不需要哪個是左哪個是右，所以，A表後面的left或者right就被省略了，直接是A inner join B on。話說回來了，為什麼要分左邊呢？很簡單，我們畫表喜歡從左往右，左邊定下了，再畫右邊，也就是，先把左邊的表查出來，再把右邊的取出來往上面拼，能拼多少拼多少。
【linq中的左右內連接】
上面第二行，我圖灰了的，是我在網上找到的right join。之所以圖黑，是因為我覺得它不對，它其實也是左連接，只是把左右兩張表順序換了而已。我也未曾找到實現right join的Linq語句。而隨著我的不斷尋找，我越來越多的接觸到一直說法，也就是，Linq與sql無關性。當然，意思並不是說linq與sql是沒有關系的，相反，它們的關系非常大，但是，如果我們想linq的時候總是被sql的想法左右，會導致一些大家都不願意看到的結果，比如有些本來很簡單的工作我們把它弄得復雜甚至無法解決。因為我們面對的不再是【表】而是【對像】。
所以，我拋開了上面那種尋找左右聯接與linq的思路，把自己想成一個不會sql的新人，去學習linq。而就在我學習linq的時候，發現linq中有許多sql裡面根本沒有的東西，而這些東西，通常是我們可以繞開sql中的復雜聯接可以直接得到的。
而且我發現，linq中的join與sql中的join完全不是一個東西，或者說，它們根本沒有血緣關系，有點兒像c與c++的感覺。
這樣，我們就必須有一種新的思路，要找尋這條新的思路，我們要先看看我們之前為什麼要尋找linq與sql的關系。
｛查詢數據的需求｝--->｛本來用sql的時候我們會寫成的sql語句｝--->｛與sql語句相匹配的linq｝
看吧，我們明知道sql轉linq沒有教程，linq轉sql微軟也沒有明確給出算法，我們卻還要這般折磨自己，何苦呢~~
那麼我們就收回那顆自以為自己很牛逼的心，把我們的做法換一下：
｛查詢數據的需求｝--->｛解決需求的linq｝
這種情況下，我們只會遇見兩人種問題：一、linq完成不了我們的需求；二、效率問題。我們先來一個個看。第一個，我覺得問題不大，畢竟是一種語言，語言都是符合語言的規格的，沒有它完不成的需求，只有它顧及不上的第二人問題。我們來看第二個問題，就是效率問題，這確實是一個大問題 ，因為，如果你寫linq寫得熱血朝天，那麼你完全可以認為，你的linq效率極低，我看見過一條linq語句，裡面有幾十個方法。linq也像sql一樣，是一種需要構造的語言，所以，在寫之前，我們必須要對linq進行深入的理解與學習，就像當初學習sql一樣，看一條sql完全可以執行它大概的執行復雜度。好了，我們的問題出來了，就是學習linq！
linq之前我也有學習過，也有用過，但是，當時太年輕了，小菜b一杦，現在，知恥而後勇，進行再學習。
