SQL 設計得爛嗎，諸如redis,nosql又該如何選擇？

12-29

感謝各位的回答，有些回答讓我收穫很多！
----------------------------------------------------------------
據王垠所言，所有的腳本語言都很爛，那麼事實上是這樣嗎？
有沒有人來點評一下 SQL，我認為和 NoSQL 出現的原因有關係吧。
不希望遞歸解釋 NoSQL，我認為就理解為不要 SQL 就行了。

我不認識王垠，但是我覺得我可能能回答這個問題。我最早是做PLSQL的，後來開始做NoSQL資料庫的研發，現在我們又在為NoSQL資料庫加上SQL語句功能。

誠如題主所言，最初NoSQL就是不要SQL的意思，為什麼會不要SQL了，其實這不是SQL本身有多爛，而是有一部分新需求出現了。互聯網公司的興趣，對資料庫有了新的要求。這些公司很多業務不在要求資料庫總是「正確」（這個詞可能不正確），而是追求高性能，除此之外，互聯網公司業務變化頻繁，所存儲的數據格式也經常變化，所以適合固定數據格式的SQL也就不適合這種需求了，於是NoSQL就出現了。

後來NoSQL的意思又慢慢變成Not Only NoSQL。這也是需求發生了變化的緣故。互聯網公司雖然收集了很多數據，但是如果不對數據進行進一步的處理，數據就不會成為有用的信息，於是大數據的概念就出來了。大數據是一個概念，如何真正地讓數據變成有用的信息，在概念提出後，就成為很多從業者所關心的熱點。當時出現了不少的方法，最有名的就是hadoop的map reduce模式，然後這些模式或多或少都有些不足。於是，人們又回到了SQL語言。關係型資料庫RDBMS，發展了很多年，很早發展出了兩個不同的大功能，OLTP和OLAP。OLAP的目的就是通過對數據進行分析處理，讓數據變成有用的信息。SQL是關係型資料庫的標準語言，其提供的函數和語句可以很好對數據進行分析處理。於是，很多NoSQL資料庫開始支持SQL或者類SQL語言，有一些新興的同類型資料庫都不叫NoSQL而自稱NewSQL。

以上說這麼多，其實想說的就是一件事情，一個語言好與壞，其實很難界定，很多時候只是它的出現，就是因為出現了某種新需求。而SQL有些不幸，它不能很好地支持多變的數據格式，它又是幸運的，兜了一個圈，它又因為其他的需求又回來了。

SQL不是一個爛語言，當然也不是一個完美的語言，有很多數據分析需求，它也不能很好的處理，於是，Mcrosoft SQL Server提供了一個sql的擴展版本T-SQL，而Oracle資料庫提供了PLSQL。

總之，一個語言很難是一無是處的，更不會是完美的，我們要做的就是找到最適合自己需求的語言。

這個問題有幾個層面上。第一是關係資料庫的這個模型怎麼樣，第二是SQL這門語言語法怎麼樣，第三是SQL系統實現怎麼樣。

第一，關係資料庫的模型比起通用的數據結構編程語言來說有所取捨，犧牲了通用性但加了很多好的性質。關係資料庫模型誕生於70年代，數據被抽象成表格，使用關係代數表達式，或者等價的relational calculus可以表達查詢。王垠批評這個模型完全可以用很簡單的數據結構表達，而查詢也完全可以用很簡單的代碼來表達。其實這個結論是完全正確的（也是完全正確的廢話），因為first order logic某種程度上確實是圖靈機表達能力的子集。關係資料庫模型的優點在於（1）聲明式查詢語言。E.F.Codd 證明了過程式的語言關係代數，和傳統邏輯學裡的一階邏輯是等價的（這句話不完全對，但大概對，不展開了），也就是說我們可以用聲明式的方法來表達查詢。用戶不需要知道資料庫怎麼操作，只需要告訴資料庫我想要什麼，滿足什麼條件就可以了，對用戶的操作要求變低了。（2）低複雜度。關係代數（即一階邏輯）的data complexity是upper bounded in logspace的，是一個P的子類。也就是說，對任何關係代數表達式，查詢一定是decidable的，只要用戶寫出合法的查詢，這個查詢一定會在數據量大小的多項式時間內結束，而且一階邏輯能表達的條件都能寫的出來。再具體來說，對於conjunctive query（大概對應select from where），data complexity是AC0（AC0 - Wikipedia），一個被認為很適合併行計算的複雜度類。相比而言，停機問題是undecidable，隨手寫個代碼還可能死循環。比較起之前出現的各種數據模型和查詢語言設計中，關係資料庫模型可能是在查詢語言的簡潔度，表達能力，和效率這幾者的平衡中取得最好的。所以，比起複雜的數據結構和無法保證查詢執行正確性的通用編程語言來說，關係資料庫模型在數據管理這樣的具體任務中，算是很好的一個抽象。

第二，SQL這門語言從語法角度設計，筆者認為一般。SQL這門語言是為了DBMS而設計的。比起抽象的關係代數，SQL（1）把查詢部分將抽象的數學模型用接近自然語言的語法來表達；（2）加入了增刪改及其它資料庫系統管理的命令。如果從語法設計的角度來說，我不是專家不好評價，從使用的角度看，我覺得還是挺簡潔和自然的，但現代發展各種標準，各種擴展各種歧義讓我覺得亂的。希望有語言學專家能來多討論一些。

第三，傳統的巨無霸式DBMS不適合各種很具體的應用需求，因此近十年孕育了很多新的數據系統。從70年代的模型，到80年代IBM DB2和Oracle兩大巨頭競爭，多年發展使得傳統DBMS是個巨無霸式的軟體。包括支持很複雜的一門獨特的操作語言（尤其是把SQL擴展成PSql等圖靈完全語言），由語言的複雜導致查詢優化的複雜，事務ACID的要求，數據讀寫的高效，分散式擴展支持，備份穩定性等等。巨無霸軟體什麼都有，都不差，但部署維護成本高，而且哪項任務都不是最好。因此數據系統在從存儲到操作的每一層，都有根據不同的取捨需求而進行改善的新系統。在我看來，NoSQL是那幾年集中出現的一批，在存儲層，放棄SQL的框架和負擔（命令執行要經過一個小編譯器，讀寫要保證事務的ACID）來提升讀寫性能的一批系統的統稱，但這樣也就放棄了前面提到的SQL那些好處。到了查詢執行層，只有KV讀寫和程序員編寫底層代碼的MapReduce不夠好用，還是希望能用很簡單的查詢語言編寫基本的數據操作的請求。近年出現了Pig，Hive，SparkSQL，Impala， Presto等大數據查詢引擎。它們針對SQL查詢使用很多新技術進行優化，也支持一定的寫操作，但就不多考慮數據存儲管理和一致性這些問題。現在的NewSQL就比較強調既要保證數據一致性，也要保證高性能讀寫，並在一定程度上保證SQL的表達能力。現在NewSQL們的設計就優先支持分散式OLTP，而在複雜查詢（OLAP）的支持就不會很多，這樣來降低查詢優化器的運行時間以提高性能。

所以合在一塊，從模型角度，關係資料庫模型抽象角度很好，數學證明了很多好性質。從語法設計角度來說，我個人認為還挺簡潔的，但也有亂的地方。從系統角度，傳統DBMS one size fit none，針對不同需求有不同系統出現，NoSQL只是其中一部分，並不能取代一切。

多讀書，少追星不好么？

多少年來，多少比王垠牛的大牛在學在用。作為都是會下蛋,懂下蛋的人，而王垠同學這麼久也沒見產個蛋出來，卻總是說其他人的下的蛋不好吃。

初學的時候感覺sql很高級啊，簡單的說就是只需描述你想要的結果，不用管過程。真使用起來才發現，數據量大的時候其實並不是這樣的，不考慮過程的話，運行速度根本難以接受，還會有互鎖的問題。而優化sql語句和資料庫結構以達到合理的查詢速度又是一門高深的學問。

有時候調整sql語句來讓資料庫引擎按照你的意願執行查詢更象是一種藝術創作。。

sql語言的設計初衷是把複雜的關係資料庫細節操作隱藏起來，暴露給用戶一個相對簡單而優雅的界面，可是然並卵，很多時候反而象是隔靴搔癢。。這與C++有異曲同工之妙。

人家是tmd 「Not Only SQL」，而不是「不要SQL」。

人丑就要多讀書。

關係型資料庫表現力差，難以擴展，就像老實人一樣，踏實穩定，但是沒有風趣。

這跟 SQL 本身一點關係都沒有，如果你發明了另一種查詢語言，但背後還是關係型資料庫，可以說是沒有卵用。

sql確實設計得爛，王垠作為程序語言專家這個判斷是很正確的。感興趣我再舉例說明為什麼。

不過資料庫不只是sql，sql只不過是資料庫很小的一方面而已。所以這個問題應該止步於抽象的語言層面。什麼關係型，什麼nosql，和王垠在語言角度說的sql爛都沒關係。那是另一個問題。

很多場景用NoSQL更合適，不是因為SQL不好，而是沒必要用大炮轟蚊子。

不能因為蒼蠅拍更適合你的某一個需求，就說大炮設計得爛。

題注混淆了兩個概念{

SQL和RDBMS是兩件事情。

Nosql對應的概念是RDBMS，不是SQL本身。

}

關於Nosql - RDBMS{

Nosql Database的出現是為了彌補RDBMS在大數據context下的不足。

他們是互補關係，不是相互取代。就好比電視劇和電影的關係。

數據量不是很大，寫入速度要求不高的情況下，RMDBS存在那麼多年自然有其存在的道理{

1，CAP中強調CA，尤其是C

2，回滾，cascade delete等等

3，各種ODBC，JDBC

}

關於SQL{

SQL的syntax不是很複雜，容易上手。Hive的hql，Cassandra的cql都借鑒了sql的syntax

底層實現不好評價，每個vendor都有自己的優勢，但別人家一個專業團隊寫出來的，大

概率還是比個人造的輪子好一點。

}

我覺得sql挺好的。接近自然語言，比較容易學習。有統一標準，這樣方便切換到不同資料庫。就是表達能力有限，有些複雜邏輯不好表達。

我覺得nosql流行不是因sql語法不好，而是因為sql背後的關係模型，它不滿足某些場景對性能和擴展性的要求。其實有些nosql資料庫支持sql語言。

NoSQL有一定優勢就是，靈活度比關係型傳統SQL高很多，不需要前期表設計，同時對於差異化數據的存儲是SQL不能比擬的。

比如某些系統里你的表結構能滿足客戶A，但是客戶B有個特殊的屬性要加到產品表，那麼欄位增加會導致客戶A這個欄位就是NULL，隨著客戶增多個性化產品屬性越來越多，那麼表的欄位就會增加到幾百個，實際上一個客戶只用到了不到10個欄位內容。

這樣的欄位浪費，不僅給開發造成麻煩，而且對於優化來說更麻煩。

NoSQL的集合結構通過允許同一個集合，不同數據結構很好的解決了這種欄位浪費問題。

當然NoSQL在關係型數據上依然不如傳統資料庫，所以目前還無法完全取代傳統資料庫。

但是個人認為，如果假以時日NoSQL能夠探索出更好解決關係數據的存儲模型，取代傳統資料庫將會不可阻擋。

畢竟隨著移動設備的崛起，系統複雜度的提高，傳統SQL的關係型結構已經越來越無法適應這種改變了。

少上知乎，多讀書。這是真理！！！

從我一普通碼農的角度，這是在知乎看到最low的問題

嫌sql不好，還有graphql……

1.sql是以從關係模型資料庫提取數據的目的設計的一種語言，推薦一本書可以看看《sql與關係資料庫理論：如何編寫健壯的代碼》

2.用過mapreduce以後再回來試一試sql，你一定會覺著sql什麼的就是神一樣的存在。如果說sql不好，請舉出什麼隨便一種數據提取語言，有嗎？好像沒有吧，不要懷疑地球人民的智力，不要妄想超越地球人的智力。。。。。。。。。

3.在目前的硬體水平下大部分時間裡開發效率都是第一位的

從語言設計方面說SQL爛，無可厚非。但這並不是NoSQL出現的原因。

你感覺不好用只是因為你沒有習慣面向set編程這是sql的本質它既不是oop也不是pop

腳本的問題：不是這樣子，語言作為工具，只要滿足了設計用途，就是好語言；銀神太偏執。

SQL是設計用於數據查詢和操作的，它很完美的滿足了這個用途，表達力足夠，執行高效（有前提），操作邏輯與數據表示解耦

nosql的用途基本上與sql是沒有太多交集的。

分散式並行資料庫的性能和可伸縮性都相當強。

SQL是DSL。

而王垠說的是腳本語言爛我沒找到出處，但是就我的認知他說的應該是編程語言。

DSL的確有爛的地方。但是非得說json缺點不能支持表達式。SQL太麻煩。在DSL不支持的領域說他的缺點我感覺就是抬杠。