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比較呢?期待後續。

發表留言

Please log in using one of these methods to post your comment:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.