虎瀾集: 網頁與資料庫 (4)
October 10th, 2016
回到問題的原點，NoSQL 是為了什麼目的而發明的? 先來看看 NoSQL 的特色:
結構簡單，高度平行化，可以很 scalable: 加節點或玩 MapReduce 都很方便。
結構簡單，所以可以容易的 replicate。
因為簡單，所以大部份的 complex query 都必須想辦法客製化。
Scalability, Replicability, Parallelization。請問一下寫網頁的諸君，您的網頁 JS 程式在 browser 端有幾個 user? 一個，很好。需要 replicate 幾份? 微糖少冰一份備份帶走，很好。您在用戶端天天跑幾千個 core 的 MapReduce 嗎? 抱歉這問題有點神經病，正常人不應該問的。現在你願意為了 NoSQL 的 scalability 和 replicability 來犧牲寫 query 的便利性嗎? 不要以為這問題很白痴，真的不少人被這個 NoSQL hype 拐到，有興趣可以去逛一下小弟和他人的筆戰。
IndexedDB 就是這種 NoSQL 概念的產物: 它存的是 objects，只提供很基本的 indexing，然後有非常奇葩的 transaction model。這奇葩的程度，可能連搞 NoSQL 的都不太理解: begin transaction，過程中寫個檔案或跑個 XHR，transaction 自動結束 auto-commit! 做與 database 不相關的 async call 會害 database auto-commit，這神馬邏輯? 偏偏人家變成規格了，還自我感覺良好擺在那裡好幾年哩! 要想寫複雜一點的 query，那和搬石頭砸腳沒什麼兩樣，這樣的規格要紅要普遍，這難度不是一般的大。
最妙的是，不管在哪裡，只要提出要弄 relational DB 的規格，就有撲天蓋地莫名其妙的反對聲浪: 你為何要復活萬惡 WebSQL? 你榨出 IndexedDB 的所有潛能了嗎? 你有什麼東西是不能用 IndexedDB 做出來的嗎? 這種鬼打牆邏輯很不幸的就是現今 W3C 規格推動者們的主流意見。因為這東西已經在那裡了，所以你不該推一個新的規格，即便它的基本假設錯了 (而且還很多人搞不清楚錯在哪裡)，除非有不得不改的理由，例如 performance 極其不好，那才可能有操作的空間。說真的，這樣的 argument 我都不知道要怎麼喬下去，已經存在的就地合法，新來的就地正法，大致上就這麼個概念。
當然日子還是要過，project 還是要交，WebSQL 不可行，所以只好撩下去用 JavaScript 寫一個資料庫了，這就是 Lovefield 的由來。
(謎之聲: 事實證明，程式庫寫的太好也會構成人家反對 relational DB 規格的理由，因為你寫的東西就很好用了嘛，幹嘛推新規格呢? 沒關係，大家就再撐著點吧 …)
|
Comments
