作者：weng hello
鏈接：https://www.zhihu.com/question/23602133/answer/40714367
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
我可以說，所有的程序設計語言都是 bullshit，最好的編程語言是自然語言，我只要跟電腦說說話，就什麼都搞定了。看，我一眼就看清楚了問題的實質，我比誰都聰明。說這樣話的人，是不是以後就沒朋友了？分割線，下面說正經的。－－－－－－－－－－－－－－－－－－－－－－－－－－－－－我算是學過數據庫的，實際上，最早的數據庫就是 NO-SQL 的，發明關係數據庫和 SQL 的那廝得了圖靈獎。學過的都知道，這是入門的常識。關係數據庫的確有很多很多的問題，這是常識，不需要任何天才都知道。但是RDBMS能解決目前遇到的很多問題，簡單的說，這玩意是個榔頭，你不能責怪他爲什麼不能開啤酒瓶。SQL 發明出來，不是爲了什麼優雅，什麼強大，那些根本就扯不上。其最初目的是爲了解決如何用最方便的辦法來查詢數據，他就是一個用來描述查詢的。當然我們都知道，最好的查詢語言是自然語言。但是目前的技術條件根本達不到，如果王大神認爲自己天才，請他去人工智能領域混吧。SQL 已經足夠好，好到很多人能學會用。而且對於現代的 RDBMS 而言，數據的查詢優化是由系統完成的。當然你說好的 DBA 必不可少，但 RDBMS 本身的優化器是無可代替的，這也是相關廠商的核心技術。使用 NO-SQL 去用編程的方式查詢數據結構，這當然可行。我前面說過，這是最原始的方法。當你碰到大規模的數據存儲或者高併發量的查詢的時候，這幾乎是唯一的方法。但這要付出巨大的代價，你要投錢，投人，投工時。對於中小項目，特別是數據特別複雜，查詢特別複雜，而數據並不是海量，查詢量也不是海量的時候。RDBMS 就特別有用。這有很多例子，比如銀行，各種企業的管理系統等等等。我一再說過，NO-SQL 是最原始的方法，並不是什麼新玩意，而且一直都存在。如果你瞭解這個領域的研究的話，相關的項目或者論文就一直沒斷過。但沒有任何一個體系能取得 RDBMS 這麼廣泛的影響，一個解決方案必然有其侷限性，汽車不能飛飛上天，飛機不會潛水，這有什麼好奇怪的呢？我也知道一種什麼地方都能去的交通工具是 “終極解決方案” ，但這有什麼意思呢？從王大神的行文來看，他對於數據庫這個領域的瞭解非常膚淺，說了一堆無比正確的廢話。也許他對於編程語言非常精通，但是對於 DB，他充其量就是抖了個機靈，說了段單口相聲，娛樂大衆而已。繼續分割線。－－－－－－－－－－－－－－－－－－－－－另外，範式本身並不是 RDBMS 所必需的，範式能解決的是數據庫的冗餘問題，數據冗餘存儲會帶來很多麻煩，最麻煩的是數據不一致的情況，如果你在兩個表裏面存了冗餘信息，而又沒有同時更新的話，就會出大麻煩。所以引入了事務，乃至分佈式事務等等這些。如果你學過數據庫，書本里都會告訴你，範式不是越高越好，適當的冗餘是有好處的，這是常識。爲什麼現在 NO-SQL 會引起重視呢，因爲對於很多互聯網網站來說，數據很簡單，而對查詢要求特別苛刻，同時又不是很在乎用戶數據的一致性和安全性，這個時候，如果你用 RDBMS 就很愚蠢。就好比你讓麥當勞給你攤個煎餅，這個有點勉爲其難。但如果你讓銀行，電信或者 ERP 系統去用 NO-SQL，這個就相當荒謬了。這種系統裏面動輒幾百張表很常見，而且查詢經常變來變去，今天讓你出這個報表，明天讓你出那個報表，而且報表又非常複雜，你用 NO-SQL 去做，光搞掂這些數據之間的關係和保證數據一致性就搞死了，不是花多少錢的問題，而是能不能搞定的問題了。
作者：Tok Tik
鏈接：https://www.zhihu.com/question/23602133/answer/25162958
來源：知乎
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。
最早的時候世界上肯定是沒有relational database這種東西的，那時候大家都在手動寫程序管理自己的數據。後來有人想，這麼幹實在比較累，乾脆做一個專門管理數據的程序吧。這就有了數據庫。創造數據庫的目的，是簡化常見的問題。設計數據庫的時候，是從實際出發，考慮怎麼樣能處理大部分的日常問題，而不是處理一切人類可以設想的問題。你也可以說這是個頭疼醫頭的辦法，但它確實也解決了大部分的頭疼。因此SQL是一種domain-specific language (DSL)，主要處理一些常見的數據庫查詢操作。用起來至少比自己重寫一個數據庫容易。你也可以說它圖靈完備什麼的，但是也沒什麼人拿它寫數據庫之外的東西。現在王垠說，SQL不能利用某些問題的特點來簡化運算。比如說，平面上的點有一些幾何性質，可以利用這些性質來簡化運算。要用SQL寫這麼個玩意就很麻煩。或者要用某些方法繞過(workarounds)，也很麻煩。這麼說肯定沒錯。普遍性的程序，要解決普遍性的問題，對特殊的問題往往就沒有很快的解法。有個no free lunch theorem，也是類似的意思。普遍性和效率沒法兼顧。可是你不能這麼就斷言普遍性的程序就沒用了。 如果要追求效率，可以用Berkeley DB之類的東西再接上隨便什麼語言，把查詢操作自己管理起來，儲存留給數據庫。如果一定要追求最高效率，可以乾脆從從數據庫底層寫起，寫一個專門用來儲存平面上的點的數據庫。你要是嫌麻煩，我就沒什麼說的了。