DDIA閱讀紀錄(5) – 第二章續：初探Graph Data Model大觀園 – 軟人手札

(進度：loc 1327 – 1668，昨天沒能抽空出來寫，因此這是兩天各讀個20分鐘左右的量。希望以後可以盡量避免這個情形)

從這個段落開始，本章堂堂從個人略懂得relational model與document-based model進入Graph data model。作者手先帶讀者認識上圖的範例，接著用PostgreSQL的語法示範這樣的資料在relational資料庫中可能會長什麼樣子，再引領讀者思考我們可以「問」這dataset的問題，例如：哪些人出生在英國但目前住在美國。透過這樣的思考練習，很快就會發現，雖然我們可以把這樣的資料在relational database裡表述出來，但query會非常難寫。以上例來說，透過「within」表現的從屬「美國」的「地區」關係很難預先說有多少層，這代表很難預先知道到底要寫幾個join，雖然有些資料庫現在有recursive join這種超魔幻的東西，但 … 就太魔幻了。在這基礎下，本章開始介紹Cypher QL與neo4j，SPARQL與Triple-Stores，以及因為異曲同工之妙而常被放在一起討論的RDF和semantic web。

因為我過去從來沒接觸過這種database，整個段落讀來讓我覺得眼界大開。雖然沒有實際用過，但我還蠻喜歡triple stores的概念的：不刻意區分vertices與edges，而是把一切都編為"subject-predicate-object"的三元組。因此，Cypher QL在撰寫時會需要考量到條件式放的是vertices還是edge，SPARQL可以不用考慮這件事。當然，實用起來我會不會還持同樣意見就是未知數了。

段落的最後作者花了一整頁的篇幅解釋Graph data model與前面提過已經凋零的network model的不同。雖然概念上同樣都是表現graph，但兩者的實際資料結構差異使。總結起來個人覺得最關鍵的差異有二：其一，network model真的把資料存儲成巢狀結構，因此要存取entities的唯一方法就是真的去巡覽整個graph；但Graph data model並沒有這個限制，必要的時候甚至可以用直接的index來存取各entities。其二：network model因為這樣的設計，只能用imperative query language而非像graph data model有很好的declarative query language可以使用。對於QL方面的差異，我想network model如果活得夠久搞不好能獲得解決，但也有可能先天上的限制讓它無法這麼做就是了。

下一段的標題是「The foundation: Datalog」，又是一個完全沒看過的東東，令人期待。

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