與資料庫有關的文章到目前為止已張貼了二十二篇文章，這些文章所談論的內容大部份都是描述資料庫引擎裡 Storage 和 Transaction 的內容．資料庫引擎裡的內容當然不只這些，還包括 SQL query parser, query optimizer, logging manager, 以及一些基本的功能如 security control 等等．光是有關 storage manager 的故事就能寫一本書了，除非你想做資料庫引擎的專家才需要知道所有的細節，不然的話，只要了解一些基本的設計便能幫助你在工作上做到更好的境界．在這些二十二篇與資料庫引擎有關的文章，我寫的那些內容其實簡化或跳過不少的細節，但那些細節並不會影響你對資料庫引擎設計的了解，只讓你可以用比較高層次的角度來檢視資料庫引擎會為你做的事情．畢竟這些內容主要的對象是給非電腦科系畢業的資訊人所參考用，因此忽略了許多數學上的推導與比較．若你是電腦科系的學生正在學習資料庫理論，請以課本內容為主，因為課本內容裡面會用一些數學來明確表達運作成本等事情．為什麼要說這些呢...
#71 資料庫引擎 - Deadlock 偵測 (Wait-For graph)
前兩篇文章談完了 table join，接著這篇文章把主題拉回到資料庫的 Transaction．
之前文章曾提過 deadlock 的發生，這在關聯式資料庫裡算是件平常可見的事情．之前曾提過當 deadlock 發生時，資料庫引擎可利用 wait-for graph 來偵測 deadlock 的發生．這篇文章將說明什麼是 wait-for graph．
Wait-for graph 是一個簡單的圖形，是一個有方向的圖形 (directed graph)，也就是它圖形上的邊具有方向性，這裡的方向性用來代表是那一個交易等待那一個交易．如下圖:
上圖的...
#70 Coding面試 - LeetCode #5 Longest Palindromic Substring
原文網址 : https://leetcode.com/problems/longest-palindromic-substring
這一題與之前曾提過的試驗字串是否為 Palindromic 的題目蠻雷同的．如果搭配 Palindromic 字串的檢驗法用在這題上，可能的解法如下:
從上面的程式碼你可以看到是將所有可能的子字串從大到小的長度逐一檢查是否為 Palindromic．因為題目是要找最長的 Palindromic，所以子字串長度才會從大到小．上述寫法的空間複雜度是 O(1)，但時間複雜度卻是 O(n3) ，主要因為有三個迴圈與字串長度是有關係的．雖然上述的寫法可以在合格的時間內通過 LeetCode 的 test cases，但若你提了這樣的 solution，面試官很有可能會再問你在空間複雜度上還有進步的空間．
如果你從第一篇文章看到現在的話，你應該可以發現我在許多文章都提過不少次...
#69 資料庫引擎 Table Join 的運行方式 - 下集
在 table join 上集的文章裡談到了最基本的 table join 運作的方式，也讓你知道資料庫引擎是如何進行 table join．你可以發現到不論用什麼方式進行 table join，資料庫引擎所處理的資料必須位在記憶體中才能被處理，因此，將資料從硬碟讀到記憶體的次數和方式將是主宰了整個大部份的執行時間．因此，要讓 table join 的完成速度變快就得在資料從硬碟讀到記憶體的過程中去下點功夫．由於資料量有大有小，記憶體的量也有大有小，所以不同情況下可能要採用不同的方法才能達到最好的效果．接下來，這篇文章來談談另一種 table...
#68 資料庫 Table Join 的運行方式 - 上集
在資料庫引擎中，table join 是一個很重要並且常見的動作．這一篇文章將討論以邏輯上來看資料庫引擎是如何進行 table join 的動作．
假設資料庫中有兩個表格，一個是學生表格，一個老師表格，這兩個表格裡都各自有一個 id 欄位用來代表學生編號與老師編號．對這兩個表格來說，這個 id 非常適合做為 primary key．學生表格裡有一個欄位是老師 id，這用來代表某學生的班導師是某位老師．這是一個一對多的關係，所以只要在學生表格上有一個老師 id 的欄位便能說明這個關係．用一個簡單的 SQL 語法可以用來表示這樣的關係
Select...
#67 IT人生 - 有關你的銀行戶頭
最近工作上和生活上寫太多 code 了，用了許多腦筋，於是今晚決定來休息一下 ，來寫篇與 IT人生有關的事情．今天的主題將和錢有關係．
由於我花了太多的時間在學校，當我在博班三年級決定離開學校去工作時，我已經三十五歲了．當時的我，口袋沒什麼錢，只是一個剛離開學校的窮人．以前二十多歲時雖然也沒什麼存款，但錢這件事並沒有真正對自己產生很大的衝擊．這樣的情況在我三十五歲離開學校後沒多久有了很大的改變，因為我當時看到了一個調查．這份調查是台灣一份財經雜誌，針對台灣三十五歲以上的人所做的調查．這份調查的內容主要是詢問被調查者在三十五歲時是否擁有超過一百萬以上的資產．根據這份調查結果，75% 左右的調查者在三十五歲時並沒有一百萬元的資產．當時才發現自己也是在 75% 的這一群人中，仔細想想，一百萬並不是很多的錢，許多人都當成是人生的第一桶金，而自己連第一桶金也沒有，這似乎是件不太妙的事情．在那之後便讓我開始重視有關錢的事情．首先要做的功課就是除了一般的工作薪資以外，還有什麼方式可以增加收入，好為自己的未來與退休生活做準備．接著找了許多資料和評估自己的情況後，我選擇的方式是...
#66 Coding面試 LeetCode #24 Swap Nodes in Pairs
原題網址 : https://leetcode.com/problems/swap-nodes-in-pairs
題目與一般的 List 題目類似，主要都是在考 next pointer 的位置安排．這一題比較特別的是兩兩成雙來交換位置，交換的邏輯並不會太難，用心推演一下就能推導出來，只有處理第一個 node 時需要做點額外處理即可．題目中有特別規定答案只能使用 constant space，也就是指你使用記憶體的量不能和輸入的 List 大小有關係．除此之外，題目也要求不能更改 node 裡的值來做交換位置的方法，所以你該做的就像一般 List 的考題來換 next pointer．參考的程式碼如下:...
#65 資料庫引擎的交易資料鎖定 (Lock) 策略
延續上一次資料庫的交易文章內容，在一個資料庫系統中同一時間可以執行多個交易 (Transaction)．在這同時執行的交易內容中，當遇到共同讀取和寫入同一個物件時，此時便有很大的機會將發生如上一篇文章中提到的資料衝突現象．為了要解決這個現象，資料庫引擎得採取一種策略．以學術的角度而言，策略有好幾種，但比較常見和合理的策略將是本篇文章中將討論的資料鎖定 (Lock)．
Lock首先定義上一段文字中所說的 "共同讀取和寫入同一個物件"，物件是指交易內容中所感興趣的資料．可能是一筆資料，例如某一個學生的基本資料，可能是符合某條件的資料，例如去年十月份的所有訂單．以邏輯處理而言，通常來說這資料可能只存在於同一個表格，但也有可能存在於多個表格．以實體上而言，資料有可能在同一個...
#64 資料庫引擎交易 (Transaction) 進行中的讀寫異常
前面的文章曾談到交易 (Transaction) 需要具有 ACID 的特性．在一個繁忙的資料庫系統中一定會有許多的交易同時執行，這篇文章便來談論許多交易同時執行時會遇到那些挑戰．
許多交易在進行時，非常有可能會遇到對相同的資料進行讀或寫的動作．如果所有的交易對相同的資料進行讀的動作，則這情況並沒有什麼好擔心的，因為所有的交易對這份資料都是讀的動作，早讀和晚讀都是同一個答案，所以不會造成任何的資料異常現象．但如果情況變成其中有一個交易或多個交易對同一份資料進行寫的動作時，那麼早寫和晚寫就會有很大的影響了．因此，我們在乎的情況便是當有交易在進行寫的動作．以下假設某個資料庫系統中有兩個交易，這兩個交易會對同一份資料進行讀和寫的動作:
如上圖所示，T1...
#63 出神入化的用介面 第三集_修改共用的介面
上一集的內容中曾提過三個團隊負責三個不同的元件，團隊一負責 ClassLibrary1，團隊二負責 ClassLibrary2，團隊三負責主要的 UI 主體 (WindowsFormApp1) 以及 CommonLibary．你可以把這三部份的功能想像成是一個普通的軟體產品．在產品演進的過程中勢必會再提供更多的功能，這可能會讓 ClassLibrary1 和 ClassLibrary2 之間的互動會更多，這也代表修改共用的介面 (在 CommonLibrary 裡) 是必需的．如果這三個團隊擁有一致的產品釋出時程，則共用 Interface 的修改並不會造成任何影響．但如果不是如此，則修改共用的...
#62 Coding面試 LeetCode #236 Lowest Common Ancestor of a Binary Tree
原文題目在 https://leetcode.com/problems/lowest-common-ancestor-of-a-binary-tree．
題目是說給你三個 TreeNode, 第一個 TreeNode 是這個樹的 root, 第二個和第三個 TreeNode 是這顆樹裡面任意兩個 TreeNode. 所以，題目都這樣說了，你就不用擔心它會給你一個不在這顆樹裡面的 TreeNode．題目問你要在任意給你樹裡面兩個 TreeNode 後，你要找出這兩個 TreeNode 最低位置的父節點．所謂最低位置是指離 root 越遠越好．
看到這題目便想到跟 TreeNode 往上走到 root 的路徑有關，因為你要找的就是從任意兩 TreeNode 出發，會在那一個 node...
#61 出神入化的用介面 第二集_物件如何在大型軟體系統中移動
在上一集中談到最基礎的 interface 應用和簡單的例子，因此從上一集的內容中應該能讓你了解到 interface 的用途之一．interface 的用途很廣，除了可以做一些物件抽象化的表示方式以外，也可以用來幫助一個物件在一個大型的軟體中不受元件範圍的限制而讓其他不同的元件來使用．在上一集的內容中，你已經看到了最基本的抽象化應用，透過 email interface 的建立，讓所有的團隊可以依照同一份 interface 的規格實做出各自所用的物件，在這一集的內容中將展現一個極為簡單的例子用來說明一個物件如何在大型的軟體系統中移動．
首先，簡介此簡單的例子，下圖是這例子中的元件，一共有四個元件:
WindowsFormsApp1.exe...
#60 Coding面試 LeetCode #199 Binary Tree Right Side View
原文網址在這裡
這題是一個標準的走訪樹節點的題目．這題多一個限制，就是只抓出每一層最右邊的節點．因此，最簡單的方法就是用 breadth first 的走法，把每一層逐漸地一層層往下走．在每一層走完要往下一層走之前，把該層最後一個走到的節點儲存到欲輸出的 List 上即可．這題參考的程式碼如下:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review,...
#59 出國工作的 Why and How?
如果自己的家鄉有個地方可以滿足自己的理想並且能得到好的待遇，我相信大部份的人會選擇留在自己的家鄉工作．就像在花蓮台東長大的孩子，若是踏上了軟體開發一途，幾乎應該都會離開自己家鄉到北部或其他地方找工作，一來工作機會多，二來待遇也比較好．相同地，如果台灣的資訊業滿足不了你的理想或期望的待遇，你一定也希望找台灣以外的機會．但從台灣到國外並不像從花蓮到台北那樣地單純．所以，我寫這篇文章是用來留下一個記錄，讓年輕人參考有什麼方式可以進行．
再談論可行的方法之前，請先好好想一想你為什麼想出國工作．以下的原因可能是大部份人的答案:
為了理想: 希望到具有規模的軟體公司接受更多的考驗來充實自己的人生經驗．
為了更好的待遇: 台灣薪資普遍低落，想追求更好的薪水．
原因可能有上百種，但這兩種應該是符合大多數人的答案之一．水往低處流，人往高處爬，這是再自然不過的事情．因此，我先就這兩個原因說明．
第一，為了理想．以台灣的純軟體開發產業來說，真的不多，若你還想找個有軟體產品賣向全世界的公司，可能用手指頭就數完了．畢竟，台灣的整體...
#58 資料庫引擎對交易 (Transaction) 的執行情況
在上次文章裡介紹了基礎的交易 (Transaction) 性質與特點，讓你可以了解為何關聯式資料庫引擎需要它．在一般的情況下，一個資料庫引擎在同一個時間內服務的應用程式非常可能不只一個，而且同一個應用程式也可能在同一個時間發出兩個不同的交易來要求資料庫引擎執行．因此，我們都知道一個資料庫引擎在同一時間執行多個來自用戶端的交易是相當平常的事情．同時可以服務多個用戶端等於是增加了整個系統的處理效能，也因為要同時服務多個用戶端，資料庫引擎的效能對於磁碟存取就會變得相當敏感．因為磁碟存取速度快，整體效能才夠快．但只有磁碟效率快就夠了嗎? 在上次文章裡介紹了交易的特點之後，你就能明白光是快還不夠，還需要在多個交易執行讀取之間不造成衝突才行．因此，資料庫引擎的設計就會面臨兩個挑戰:
1....
