反對SQL與捍衛SQL的論戰

1. Jamie Brandon首次發表了反對SQL：
首先他認為關聯式資料庫好處是：

• 共享的通用資料模型允許以多種不同語言編寫、在不同機器上執行並具有不同生命週期的程式之間進行協作。
• 規範化允許更新資料而不必擔心忘記更新派生資料。
• 物理資料獨立性允許更改資料結構和查詢計劃，而無需更改所有查詢。
• 宣告性約束清楚地傳達了應用程式不變數並自動強制執行。
• 與命令式語言不同，關係查詢語言沒有由迴圈計數器和可別名指標建立的虛假資料依賴性。這使得關係語言：
  
  • 非常適合現代機器。可以重新排列資料以獲得更緊湊的佈局，甚至是自動壓縮。操作可以重新排序以獲得高快取區域性性、管道友好的熱迴圈、simd 等。
  • 適合自動並行化。
  • 適合增量維護。

• 缺乏表現力：SQL 是一種特別缺乏表現力的語言。許多簡單的型別和計算根本無法表達。結構是脆弱的——對計算的小改動可能需要對程式碼進行大的改動。
• 不可壓縮：如果一個計算在多個地方使用，我們可以將它分配給一個變數，然後在這些地方使用該變數。或者，如果計算依賴於每個地方的不同輸入，我們可以建立一個函式並將不同的輸入作為引數傳遞。
• Non-porous：雖然單個資料庫可以透過多種方式進行擴充套件，但擴充套件不能在資料庫之間輕鬆共享，並且 SQL 規範仍然試圖吞噬整個世界。

• 複雜性嚴重拖累了執行時和工具的質量和創新：因為 SQL 是如此缺乏表達、不可壓縮和不可移植擴充套件，所以它永遠無法開發一個庫包生態系統。如果你開發一個新的 SQL 實現，你也必須從頭開始實現整個生態系統，因為使用者不能自己實現它。
• 需要在資料庫和客戶端之間進行手寫協調的應用程式層使關聯式資料庫的大多數最佳功能變得無用：關聯式資料庫的最初想法是直接從客戶端查詢它們。隨著網路的興起，這個想法消失了——SQL 太複雜了，不能輕易地防止對抗性輸入，SQL 查詢的快取失效太難了，並且沒有辦法輕鬆地產生後臺任務；ORM 容易出現n+1 查詢錯誤和野生併發。換句話說，它們不擅長高效查詢資料，也不擅長利用事務——關聯式資料庫的兩個核心特性。
  GraphQL的成功表明這些痛苦是真實存在的，而且人們確實希望直接從客戶端發出豐富的查詢。與 SQL 相比，GraphQL 更容易實現，更容易快取，攻擊面更小，具有各種壓縮常見模式的機制，易於遵循外來鍵並返回巢狀結果，具有一流的互動機制外來程式碼和外部世界，擁有豐富的型別系統（有聯合型別！），並且很容易嵌入到其他語言中。

• SQL 語言中的設計缺陷導致語言沒有庫生態系統和限制創新的繁重規範。
• SQL 資料庫介面中的其他設計缺陷導致將盡可能多的邏輯移至應用層，並限制了資料庫最有價值功能的使用。
• 現在修復其中任何一個都可能為時已晚。

2. Pedram Navid捍衛SQL文章：
Jamie Brandon 反對 SQL 的宣言認為 SQL 很糟糕，而且糟糕到影響了整個行業。SQL 的問題歸結為它的無表達性、不可壓縮性和不可移植性。我的目標不是反駁他的觀點，Jamie 的大部分論點都反對幾乎沒有人與之互動的語言部分，其餘部分已經有了一些非常好的解決方案。我真正擔心的是，它會阻礙人們學習 SQL，並使那些以 SQL 為主要語言的人感到不合適。
一般而言，軟體工程中圍繞資料存在一種持續的、不言而喻的光環。“軟體工程”和“資料人員”之間幾乎被劃分為兩個階級。對於資料分析人員而言，分析資料很難：生態系統很難。資料很亂。很難測試。我們還沒有找到正確的工具、正確的除錯、正確的環境，甚至還沒有找到正確的教學方法。
從事這項工作的人並不缺乏技能。他們使用的工具和語言也同樣有用，因為它們沒有其他語言的特性。他們對業務感同身受，並且有著無窮無盡的好奇心。資料人員是我見過的最聰明、最善良的人。
因此，雖然可能有人反對 SQL，但要知道我們中的許多人都非常支援 SQL。世界因它而變得更好。
  

3. 業務分析正處於十字路口。
關於SQL 的缺點在於“幾乎沒有人與之互動的語言部分”。來自分析師的分析正處於十字路口則也是反對SQL，認為SQL技術會阻礙排斥更具有分析思維的人才進入資料分析等軟體工程行業：
Jamie 的原始帖子認為 SQL 不符合其他現代語言所做的許多標準；因此，根據 Jamie 的說法，建立在 SQL 之上的整個分析大廈存在無法彌補的缺陷。
Pedram 不同意其優點，稱 SQL 的缺點在於“幾乎沒有人與之互動的語言部分”。我傾向於這個觀點。我幾乎每天都使用 SQL 近十年，我甚至不理解Jamie的許多擔憂，更不用說對它們感到沮喪了。
分析師必須啟動資料庫、管理 Docker、執行 Python 環境、開發測試框架，並維護一個由不匹配的內部工具和第三方應用程式組成的脆弱的 Rube Goldberg 機器。Pedram 認為，這可能看起來不像傳統的軟體工程，但它是工程，很難，而且不能被忽視。 
這是事實，但Pedram迴避了更基本的一點：分析主要不是技術性的。 雖然技術技能很有用，但它們並不是普通分析師與優秀分析師的區別。當有人質疑我們是否是真正的工程師時，我們不應該覺得有必要拿出我們的技術證照。我們應該說，“那又怎樣？那不是我們的工作。” 
如果我哥哥 Will 申請矽谷的資料分析師工作，他會立即被拒絕。他的簡歷上的任何內容都不會引起招聘人員注意：他擁有法律和歷史學位，而不是 STEM；他熟悉 Excel，而不是 Python 或 SQL；他是一個分析性的思考者，但不符合如大多數科技公司職位列表的技術引數所定義的分析師。 
然而，如果他想要從事這樣的職業，他會和我們任何人一樣擅長。他是全國領先的城市人口學專家之一，這個主題比幾乎任何行業關注的問題都更加結構化和數量上覆雜。他經常使用比最雜亂無章的公司資料庫還要混亂和繁瑣的政府資料來源。儘管為一個距離華盛頓特區一千英里的相對默默無聞的組織工作，他透過看到其他人看不到的東西，尤其是透過更好地描述這些想法而在美國政治的“話語”中贏得了一席之地。
考慮到一個細微的問題需要敏銳的眼光、分析的頭腦和有說服力的筆來推薦具體的解決方案，我哥哥是一個完美的人選。
正如 Pedram 所暗示的那樣，用技術術語定義分析師會將人們排除在他們有資格從事的領域之外。 
 
banq總結：SQL與分析思維是兩種不同技能，SQL技能可以短時間學習培養，分析思維培養確很難，對複雜系統的洞察力和邏輯能力可以透過其他形式邏輯方式培養，SQL語言如同數學語言或幾何語言一樣都是形式邏輯語言的一種而已，如何吸引更優秀人才進入網際網路或計算機軟體工程行業，也許SQL是一個障礙。