本文僅用於學習和交流目的，不得用於商業目的。非商業轉載請註明作譯者、出處，並保留本文的原始鏈接：http://www.ituring.com.cn/art...
訪談嘉賓：MICK， 就職於日本的一家系統開發公司，是性能方面的工程師。專業領域是BI/DWH之類的大規模數據解析系統的設計和性能優化，如果發生性能問題，也會去應對OS資源或者Java的內存解析等各個方面。此外，最近也擔任培訓工作，培養公司內部的年輕工程師。
從學生時期開始，MICK就一直是合唱團（choir）的一員，不過最近的興趣主要是做孩子的玩伴。
【推薦語】
本書針對那些初次接觸SQL和關係型數據庫的讀者，幫助他們從SQL的基礎知識開始學習，包含從最初的SELECT／UPDATE／DELETE這些SQL的基本語法，到CASE表達式、表結合、關聯子查詢、窗口函數等重要功能的知識點。此外，由於本書以標準SQL的語法作為基礎進行學習，所以不論數據庫產品有什麼差別，都可以作為一項便攜有用的技術常伴身邊。——MICK
訪談實錄：
日文版
個人話題
技術人士給人的印象一般會比較“宅”，生活中您是怎樣的一個人呢？
去年秋天，我的小孩兒出生了，所以現在的個人時間基本上都是陪孩子的。一起去動物園啊（新聞報道了熊貓寶寶出生的消息），一起玩玩具什麼的。雖然能夠親眼看着孩子成長是件非常快樂和令人感動的事，但孩子身上總也用不完的能量和精力，對於陪伴他們成長的父母來説卻是很頭疼的事情（笑）。現在，基本上沒有什麼時間學習技術，也是挺苦惱的。
日本技術圈會通過哪些形式相互交流、學習呢？
日本這邊的學習會和研討會特別的頻繁和活躍。雖然時間基本上多數是在平日下班之後舉辦，但仍然有很多人在繁忙的工作中擠出時間來參加。這樣的學習會有時會分行業舉辦，有時也會以特定的技術領域（DB、Java、Ruby、機器學習等）為主題舉辦。我自己也會參加DB的學習會，還曾經被委託做過演講。因為這不僅僅對自己，而且對整個IT行業的發展非常重要，所以在接到委託的時候，我基本全都會接受。
日本是個講究效率的社會，生活節奏相對較快。您做到兼顧工作、生活、寫作的秘訣有哪些？
秘訣啊......好難啊（笑）。坦白説，20多歲的時候，是憑體力。那時候公司的工作很忙，晚上很晚才能回家，回家後常常也會繼續學習或者寫書。但是這樣肯定不能持續太長時間，那只是年輕時的特權而已。説到竅門，就是活用間隙的時間。我是坐電車上下班的（到公司大概45分鐘），從智能手機普及以來，我就會在電車中把突然浮現出的文章記錄下來，或者翻譯英語的技術報道，回一回郵件，整理瑣碎的任務，等等。這樣就可以有大量的時間用於學習和寫書等真正重要的活動了。
寫書話題
什麼契機讓您開始編寫技術書的？
最初，我是在自己的個人網站上刊登技術相關的信息。
本來並沒有寫書的打算，只是想把備忘錄跟大家分享而已。後來，看過網站的出版社編輯給我發來了為網絡雜誌編寫技術報道的邀請，我接受了那個邀請，慢慢開始成為了一個撰稿人，繼而開始寫書。
《SQL基礎教程》出版以來，廣受讀者好評，您認為這本書受到讀者喜愛的原因有哪些呢？
能在日本和中國兩個不同語言的國家都受到好評，我真的非常高興。我在寫這本書的時候比較注重的是“寫一本當自己還是初學者時想要讀的書”。不僅是SQL還有那些編程語言的入門書，基本上都不會對詳細的原理進行講解，“暫且記住這麼寫”這樣的內容也很多。這些就是所謂的“料理書”或者“食譜”書。對我來説，即便是入門書，我也不會採用這樣的寫法。因為如果最開始不理解其中的原理，終究無法脱離初學者的階段。
要寫出如此淺顯易懂、細緻入微的入門書，需要對事物有細緻的觀察和深刻的理解，請問您是如何做到的呢？
確實，我非常注意不能疏於“對事物細緻入微的觀察”這一點。換句話説，就是“不能無視細小的不協調”。 開始學習某個領域的時候，我常常會帶着“為什麼會這樣呢”這種疑問，並且從不無視這樣的疑問，認真調查直到真正解決問題為止。
例如，最開始學習SQL的時候，如果要檢索NULL，我們不能用“<列名> = NULL”，必須寫成“<列名> IS NULL”，這樣的語法規則非常不可思議。為什麼不能使用“=”呢？這樣的疑問，如果不深究，只是按照“就是這樣寫的”背下來，也是可以的。但是，這樣做就無法掌握實際的應用能力，很快就會遇到成長的瓶頸期。我認為，能夠達到理解本質的最好方法，就是不要無視見到的瑣碎疑問。“上帝存在於細節之中(God is in the details)”是我的座右銘之一。
未來有第三版的寫作計劃嗎？如果有，會在哪些方面對第二版進行補充或更新？
雖然現在還沒有第3版的寫作計劃，不過如果作為補充的話，我會考慮以下兩種方式。一種是加入SQL的應用技術。現在，SQL作為大數據加工分析的工具，出現了很多比以前更高級的用法。通過活用窗口函數和CASE表達式，可以創建出非常方便的程序。目前已經出版了的兩個版本都是停留在基本使用方法的講解上，所以正在考慮擴充一些順應時代的內容。另一種是加入關於SQL/RDB在系統開發整體中位置的説明。例如，追加一些類似SQL注入原理和對策，針對實際系統開發中如何應用SQL/RDB的內容。
技術書翻譯
我們知道，您曾經翻譯過Joe Celko的書，關於Joe Celko和他的著作，可以説一下您的看法嗎？
Celko的 Joe Celko's SQL for Smarties 是我學習SQL時的教科書。可以説，關於SQL的幾乎所有知識都是從他那裏學到的。這是一本非常龐大並且難懂的書，所以讀起來非常辛苦。實際上，我寫書的動機之一，就是“想把Celko的書講解得更加容易理解”。説起來，我的書其實就是對Celko書的註解。
作為譯者，您是怎麼決定是否翻譯某本書的呢？
現在，我正在翻譯Celko的另外三本書。從20歲出頭開始讀他的書以來，就一直非常地尊敬他，所以一直想什麼時候能有機會翻譯他的書。我自己甚至有向出版社提案的那種熱情。除了Celko以外，也有很多非常好的數據庫方面的英文書，也希望什麼時候能翻譯這樣的書。
翻譯技術書，對譯者的現有知識有哪些影響？翻譯過程中，譯者會加入一些自己的理解或建議嗎？
如上所述，Celko的書非常難懂，僅讀一次無論如何也無法理解。所以，翻譯的時候，會加入很多能夠讓讀者容易理解的註釋。另外，不贊同作者意見的時候，也會努力做到表明自己的觀點，為讀者提供可以自己思考的機會。
在中國，存在着大量針對以《論語》為首的深奧古籍的註解書。像朱熹的《論語集註》和何晏的《論語集解》，在日本也有廣泛的讀者。這樣的註釋文本不僅僅是説明語言的意思，並且加入了很多獨立思考的內容，非常有創造性。我也希望像這樣，不做單純的語言變換，而是以為原書帶來更多的附加價值為目標進行翻譯。
關係型數據庫和非關係型數據庫
可以簡單介紹一下關係型數據庫和非關係型數據庫（NoSQL）的特點及適合的應用場景嗎？
NoSQL剛出現的時候，就有一些關於它會不會取代關係型數據庫這樣的説法。但是經過了這麼多年，現在已經穩定在了“適才適所”的形式上。NoSQL的種類非常多，所以無法一語概之，比較有代表性的是按照種類來區分。
(1)Key Value Store (KVS) Memcached、Redis、DynamoDB(※)等
(2)文本型DB MongoDB、DynamoDB等
※也具有文本型DB的功能。
我覺得(1)的優點有兩個。一個是通過將數據構造進行Key-Value這種一對一的單純化處理，使高速查詢變成可能。放棄SQL查詢的自由度，取而代之的則是對速度的追求。使數據增加時的可擴展性更加豐富。通過KVS，特別是將數據內存化之後，可以使性能獲得提高。
(2)的優點是，通過JSON和XML等形式，可以將過去關係型數據庫中以“表”的形式存在、比較難處理的數據，變得非常自由。這樣，就可以用來處理那些沒有進行正規化嚴密設計的各式各樣的數據了。
不過，不管是哪種類型，都會犧牲掉關係型數據庫那種高度的事務處理功能和數據安全性。從“結果一致性”字面意思就能知道，它只能保證數據變更後最終保持在正確的狀態，允許有暫時的不一致。因此，(1)可以應用於“需要高速應答，允許某種程度的數據不一致和消失”的數據處理。具體來説，就是像SNS投稿那樣的流數據或者EC網站中用户的Session信息，等等。對於Session信息來説，即使是最糟糕的丟失狀況，也可以通過再次登錄來重置。可是那些已購商品記錄和付款數據的消失是絕對不能允許的。因此，類似這樣的情況就需要使用KVS作為前台，關係型數據庫作為後台這種常規的設計。
此外，還有一些用來處理非結構數據的數據庫（雖然對其是否可以稱為NoSQL仍存在意見分歧）。總之，就是類似於圖像和聲音等非文字數據，以及像圖形結構這種過去的關係型數據庫處理起來比較棘手的數據。這樣的數據庫，是專門用來處理那些關係型數據庫無法處理（或者難以處理）的數據的，在特定用途領域，也有取代關係型數據庫而存在的可能性。
但是，儘管如此，因為關係型數據庫的穩定性和泛用性非常傑出，所以使用關係型數據庫構建核心系統，在更加輕便的前端等細分領域使用NoSQL，這樣的形式今後會一直持續下去。
非關係型數據庫（NoSQL）將來會成為數據管理的未來趨勢嘛？
我認為NoSQL有兩個發展方向。一是NoSQL今後還有獨自發展的可能性。另外就是它作為關係型數據庫的一個功能被吸收的可能性。實際上，過去的XML數據庫，最初是作為獨立的數據庫產品出現的，可現如今已經作為大多數DBMS的一個功能被吸收了。即使現在，關係型數據庫也存在擴充處理JSON和地圖信息（Spatial DB）的功能，最終成為一個包含NoSQL功能的“大家族”的可能性。不管怎樣，我想作為工程師，學習如何處理非結構數據的技術今後都會越來越重要。
後輩寄語
您認為，新手在學習SQL時有哪些平時需要培養的習慣？在效率和規範性等方面，能否給出一些建議？
我想應該是，最開始不要去熟記那些小聰明式的技巧和“秘訣”，而是能夠用心去理解動作原理吧。SQL跟Java等其他編程語言相比，因為其函數和功能的數量比較少，又接近英語這種自然語言，所以乍一看很簡單。但實際上，那些“簡單的功能”（關聯、CASE表達式、窗口函數、HAVING語句，等等）組合到一起，就會變得極為複雜。這一點上SQL可能跟積木很像。如果忽略了對每個基礎積木塊的理解，那就絕對不可能做出很高的建築物。
如果以後想從事軟件開發工作，初學者在學習完《SQL基礎教程》以後，還需要在哪些方面努力？您能否給些專業的建議？
本書終歸是聚焦於幫助大家理解SQL語法這一目的。實際上，對於技術人員所必需的知識而言，這些SQL的知識是遠遠不夠的，所以希望大家能夠將目光投向更廣闊的領域。例如，即使只是在數據庫領域，也存在類似ER建模，Oracle、MySQL等產品的設計技術，SQL性能優化等，都是需要花很多年來學習的技術領域。如果各位讀者是軟件開發人員的話，我想也必須學習Java、PHP、Python等開發語言吧。
大家的目標是什麼，這是由大家自己的職業意向和市場需求決定的，所以我不能一概而論地給出建議。但不管是哪個領域，帶着興趣學習是非常重要的。因此，儘早找到自己能夠保持學習動力的領域，能夠持續保持興趣地進行工作，是非常重要的。
在軟件概要設計的初期，不同的項目需要選擇不同的數據庫。您能否簡單介紹一下該怎樣選擇合適的數據庫？
現在，在日本可以選擇的關係型數據庫有Oracle、SQL Server、DB2、PostgreSQL、MySQL這5個代表。如何選擇，對技術工程師來説是非常重要的問題，是必須綜合考慮多種因素的難題。
但現實中，有時候我們並沒有選擇權。一句話，就是常常會受到“錢”的制約。譬如在公司啓動，需要建立新服務的時候，為了儘量降低許可證的費用，除了PostgreSQL和MySQL這些基於OSS的數據庫以外別無選擇。而如果是為金融機構和公共機構構建那種追求非常高的可用性和性能的系統時，則必須選擇Oracle這種具有高功能並且能作為供應商提供細緻周到的支持服務的產品。又或者是EC網站之類的信息流量隨季節變動比較頻繁的場合，選擇Amazon RDS之類基於雲上的，作為SaaS的數據庫，可能是性價比最高的。
近年來，任何一種數據庫產品，在功能的充實性方面都難分伯仲，因此跟過去的選擇基準相比，上面給的預算制約、非功能性、支持的充實度等方面就變得更加重要了。
關於提高SQL的性能，可以跟我們分享一下您的經驗和建議嗎？比如複雜SQL（多表嵌套查詢，關聯查詢）或存儲過程中，一般在什麼地方容易引發性能問題？
SQL性能優化是我的專業之一。雖然SQL非常容易引發性能問題，但其實坦率地説，主要還是因為數據庫處理的數據量太大引起的。Web服務器和AP服務器最多隻能處理能夠保存在內存中的那個水平的數據量（GB級別）。但是，在數據庫服務器上處理TB級別的數據卻是理所當然的。近年來，隨着大數據的流行，數據量也逐漸增大。
這必然會使從存儲器中讀取數據時的速度成為難以超越的瓶頸，也就造成了很多SQL的性能問題。特別是在進行大表關聯的時候，這樣的問題更加顯著。
如果要在本次採訪中講述解決辦法的話，篇幅可能不太夠。我計劃寫一本專門針對SQL性能改善的書。但是，如果要舉一個馬上可以實踐的改善方法的例子的話，那就是在DB服務器上儘量多的搭載物理內存，給數據庫分配更多的內存好讓數據庫可以使用更多的內存。以前，內存的價格比較高，但最近正趨於低價格化，32GB或者64GB的內存，都可以毫無壓力地搭載在一般的DB服務器上。內存與一般的HDD相比速度要快很多，如果能在內存上保存數據的話，就可以解決很多性能方面的問題。雖然這只是用金錢來代替頭腦的解決方案，不過因為這種投資效果顯著，所以還是比較推薦的。（笑）
如果要舉一個設計上需要注意的例子，那就是儘量減少SQL處理的數據量，把它作為基本方針。那些幾乎不需要的舊數據可以轉移到歷史數據表中。對於能在畫面上設定的數據查詢條件，儘量讓用户來設定，等等。
SQL性能優化是針對通過設計上的努力也無法解決的問題的最後手段。不要從一開始就依賴SQL性能優化，不需要SQL性能優化的設計才是非常重要的，這一點請大家牢記。
特約記者：
孫淼，從事對日軟件設計和研發工作十餘年，曾於2007年至2009年赴日學習工作，2015年至今再次長期赴日工作。精通應用Java、PHP進行Web框架的設計開發，並且有Oracle、Teradata、MySQL、NoSQL等多種數據庫的設計開發經驗。樂於品味生活細微的點滴，熱衷於品嚐和製作美食。是《SQL基礎教程》的譯者。
