DDIA閱讀紀錄(2) – 第二章：從Relational model到Document-based model

(本次進度：從location 737到907，這本kindle版沒有與實體書對應的頁數，只好用location number)

首先看看那張精美的data model地圖，除了繪製功力相當高超外，仔細看會發現每個「地點」和「道路」似乎都是有它的道理的。

本章開頭幾個段落相當精彩，首先從relational model於1970年初次由Edgar Codd提出說起。它接下來數十年間奇蹟般地歷久不墜，甚至從企業級資料處理逐漸普及，如交易資料、物流資料、甚至批次處理的資料存儲，甚至現在移動裝置上也有SQLite了。

25 – 30 years –– an eternity in computing history.

我蠻喜歡作者這樣的形容，這確實是項不簡單的創舉。

背景簡單介紹完，接下來作者進一步從資料間的關聯性去深探：1-to-1，1-to-n，n-to-1與n-to-n。我們當然可以說一切都是n-to-n的特化型，但實務上怎麼架構這些關係的是天差地別。relational data model自然可以透過正規化等手法去構築，但很快就會碰到「object-relational mismatch」或說「impedance mismatch」的問題。也就是資料在應用程式中的概念表述是「物件」時，會需要轉譯成relational data model，而這層轉譯往往不太直覺，而且常常會需要多次的query來完成。impedance mismatch、儲存並直接檢索structured data的需求、以及更好的擴增性等等需求，促生了document-based data model，而其中很重要的一支便是NoSQL。

令我相當開心的是，從這個部分開始整本書的走向開始進入比較實務的部分了。例如正規化，以及為何document-based data model常常會需要靠application code來實作n-to-1或n-to-n的關係，但書中僅是很精要地提及並帶過，沒有在實務上被這些情境狠狠痛打過的人可能很難深入體會就是了。

這裡順便加一點個人想法。實務上impedance mismatch還有一個方法可以處理，就是不要用物件導向的方式來設計，而是用資料導向設計(data-oriented desgin)。後者在我離開遊戲業時是大宗，我相信現在也還是；在functional programming上似乎沒有人會用這個詞，但大部分的時候只要在寫FP幾乎就是自然而然在用了。將來有機會可以寫篇文章介紹一下。

接下來本書會怎麼從正反面去討論NoSQL乃至general key-value data model，會如何去回頭和relational data model比較呢？期待後續。

啊...啊啊啊... _(´ཀ`」 ∠)_ 觀看 James Tien 的所有文章