跳到主要內容

T-SQL Join 的筆記


 雖然這不是什麼困難的事情,網路上也有很多的資源,但偶而還是會搞混,因此想要好好的搞清楚。 Join 應該都會用兩個圈圈的圖片來代表兩張資料表,然後看是怎樣的 Join 就會塗上資料範圍的顏色 (如下圖)。

但是碰到蠻多人會說 Cross Join 或是 Outer Join。其中 Cross 我是真的不知道。但是 Outer Join 是存在的。因為除了 Inner Join 之外的應該都屬於 Outer Join。像是 Left Outer Join, Right Outer Join 以及 Full Outer Join。

而 Inner Join 的語法也可以簡化成 Join 就好。

最後補上其實還有 Self Join,語法如下,連 Join 都不用寫

  SELECT a.custid , b.custid
  FROM customer a, customer b 
對了! 在 MySQL 只有 Inner Join, Left Join, Right Join 而已。

留言

這個網誌中的熱門文章

[學習iOS之路] Lifecycle 比較

在開發Android很多年之後終於開始學習寫iOS了 契機就是工作需要,果然工作需求就是推開最大靜摩擦力的原動力啊! 在這邊寫下學習Swift的一些筆記,希望在自己忘記或是需要給別人教學的時候可以起到一點點作用。 因為對Android比較熟悉,所以透過比較來熟悉iOS架構 首先是iOS與android的比較 可以參考這張圖 Android vs iOS lifecycle 與這張 iOS 詳細state 流程 Android lifecycle OnCreate -> OnStart -> OnResume ->(running) -> OnPause -> OnStop -> OnDestroy                        ^                  ^                                  |               |                         |                  |-------------------v               |                         |-----<-----   OnRestart   ------<---------v iOS lifecycle LoadView -> ViewDidLoad -> ViewWillAppear -> ViewDidAppear -> (running) -> ViewWillDisappear -> ViewDidDisappear -> ViewWillUnload -> ViewDidUnload -> dealloc 於ViewDidDisappear之後view就看不見了,如果view要再次被看到且view還存在 那就會是ViewWillAppear,否則就是LoadView從頭開始 下一篇是語言的比較 Java vs Swift

Docker vs VM 的學習

工作上用到 Docker 也一段時間了,剛接觸到 Docker 時常常會聽到別人這樣解釋," Docker 的 Container 技術,類似於 VM 。差別是 Container 比較小,沒有包含 OS,而 VM 會包含 OS"。 這段話我覺得不算是全錯,所以我一開始也是這樣去解釋給別人聽,直到我聽到我同事在面試求職者時問了這句話,"如果 Container 比較快,比較輕量,優點這麼多,為什麼 VM 沒有被淘汰?" 我才忽然意識到,我並沒有真正瞭解這兩種技術的差別。 事實上,這件事情要從解決問題的角度上出發去理解。任何技術的產生應該都是為了解決某些痛點,從這點來思考的話網路上就有很多文章可以查到了,我把我查到的最清楚的文章連結放下本文最下方,有興趣的可以去看看。 VM 是為了解決硬體的資源共享的問題所產生出來的技術,而這個需求仍然存在,並不會因為有了 Docker 的 Container 技術就取代了。這個可以回答為什麼 VM 沒有被淘汰。因為要解決的問題不一樣,事實上很多 Container 還是跑在 VM 裏頭,可謂是相輔相成。 那 Docker 是為了解決什麼問題才發明的呢? 我的消化與理解是 "解決建置環境的複雜度" 而發明的,每個 Dockerfile 會指定使用的映象檔(image),然後寫下需要安裝的 Tool 指令。按照這個 Dockerfile 上面列下的指令去安裝與建置,就可以重現執行這個 APP Runtime 所需要的環境。這解決了以前工程師常說的那句話 "在我的電腦上跑得好好的,為什麼在正式環境就行不通" 的問題。   參考連結

C# CSRF attribute 的錯誤追蹤與處理

最近開發網站碰到一個問題,有時候可以登入成功,有時候不行。但明明帳密都是 Google 記憶的,不可能打錯帳號密碼。後來猜想到是 CSRF 認證的問題,由於網站是透過 k8s 建立的,且 replicas: 2。很大可能性是因為拿 token 是跟 A Pod 拿,但登入是跟 B pod 登入,造成 token 無法驗證成功。 想證明這個問題,我們必須去紀錄 Log,由於我們是透過 C# 的 ValidateAntiForgeryToken Attribute 實作 CSRF 的防禦,因此一開始想法是寫一個 ExceptionFilter 去攔截例外。但發現無法攔截 CSRF 的問題。後來找了一段時間發現,CSRF 並不是丟出例外,而是結果回覆 HttpStatusCode 400。查到可實作 IAlwaysRunResultFilter 攔截結果,並判斷是否是 IAntiforgeryValidationFailedResult 的一種。 程式碼如下:  public void OnResultExecuting(ResultExecutingContext context) { if (context.Result is IAntiforgeryValidationFailedResult result) { // Log here } } 但是這樣還不夠。還必須要強制關閉客戶端錯誤的轉換才行,這樣才可以精準的把結果視為 IAntiforgeryValidationFailedResult 至於怎麼關閉則是在註冊 MVC 服務的時候設定 Config SuppressMapClientErrors = true 即可。      services.AddMvc().ConfigureApiBehaviorOptions(options => { options.SuppressMapClientErrors = true; }); 詳細可以參考 MSDN