4.1模型的映射
我將它簡化一下僅保留item、attributeGroup和relationship, 如下
<!--[endif]--> CREATE TABLE identifierObject ( id INTEGER PRIMARY KEY ) ; CREATE TABLE itemObject ( ) INHERITS (identifierObject); CREATE TABLE item ( ) INHERITS (itemObject); CREATE TABLE relationship ( id INTEGER PRIMARY KEY, source INTEGER NOT NULL REFERENCES item (id) ON UPDATE CASCADE ON DELETE CASCADE, destination INTEGER NOT NULL REFERENCES item (id) ON UPDATE CASCADE ON DELETE CASCADE, UNIQUE(source, destination) ) INHERITS (itemObject); CREATE TABLE attributeGroup ( id INTEGER PRIMARY KEY, ownerid INTEGER NOT NULL REFERENCES item (id) ON UPDATE CASCADE ON DELETE CASCADE ) INHERITS (identifierObject); CREATE INDEX a_idx ON relationship (source); CREATE INDEX b_idx ON relationship (destination); CREATE INDEX c_idx ON attributeGroup (ownerid);-–確保它不與自己發(fā)生關系ALTER TABLE relationship ADD CHECK (source <> destination) ;
現(xiàn)在模型建立好了,我們可以開始對它進行操作了.
4.1.1創(chuàng)建
這個不用說了吧
4.1.2刪除
刪除一個條目
DELETE FROM item WHERE id = 2; --因為相關的relationship和attributeGroup有CASCADE選項,與之相關的關系和屬性組會自動刪除
刪除一個關系
DELETE FROM relationship WHERE id = 3;
刪除一個屬性組
DELETE FROM attributeGroup WHERE id = 6;
4.1.3更新
這個不用說了吧
4.1.4查詢
呵呵,普通查詢我就不說了,我們說說圖查詢吧.
4.1.4.1簡單一級的查詢
查詢id為1的條目相鄰的條目
<!--[endif]--> SELECT * FROM item n LEFT JOIN relationship e ON n.id = e.source WHERE e.id = 1; -- 查詢id為1的條目相鄰的條目
4.1.4.2復雜一點的遞歸查詢
從id為1的條目出發(fā),詢它沿關系能到達的條目,并返回路過的中間節(jié)點的個數(shù)和路徑
<!--[endif]--> WITH RECURSIVE transitive_closure(source, b, distance, path_string) AS( SELECT source, destination, 1 AS distance, source || '.' || destination || '.' AS path_string FROM relationshipWHERE source = 1 -- source UNION ALL SELECT tc.source, e.destination, tc.distance + 1, tc.path_string || e.destination || '.' AS path_string FROM relationship AS e JOIN transitive_closure AS tc ON e.source = tc.destination WHERE tc.path_string NOT LIKE '%' || e.destination || '.%')SELECT * FROMtransitive_closure
4.2討論
我對postgresql進行過測試,在這種繼承結構下,它是很低效的,一般來說你對一個父表進行查詢時,它會依次對派生表進行查詢的,當派生表太多時,它的查詢時候基本上變成了你查詢每一個表的時間總和的三分之一(這好像是依賴于查詢的并發(fā)數(shù))。此外繼承還有一定的局限性。
因此我想既然item表中沒有用戶定義的屬性,那么父條目與子條目的屬性是相同的(有一些系統(tǒng)定義的屬性),那么條目(item)的繼承我們可以不用表繼承的方式實現(xiàn),而是加入一個表示它的類型的字段。當你查詢指定類型的條目時,可以在where中加上一個 type = x的過濾表過式,而這個表示類型的字段的設計請參見層次型枚舉。
將對象的類型改成一個字段來表示,還有一個好處就是用戶可以更改對象的類型,而這樣子更符合面向對象的思想。
5.后記呵呵,這個數(shù)據(jù)庫是我為公司設計一個CMDB原型時開始構思的,花了8天完成了本文。其間對數(shù)據(jù)庫了解從僅知道簡單的Select到了解分區(qū)、物化視圖、自定義操作符、公共表表達式(Common Table Expression,CTE)。感謝Google,讓我可以查到大量的資料。
原文:http://www.cnblogs.com/runner-mei/archive/2010/09/15/1826219.html
本文鏈接:http://m.95time.cn/tech/program/2010/7966.asp
出處:博客園
責任編輯:bluehearts
上一頁 GraphDatabase在關系數(shù)據(jù)庫中的實現(xiàn) [7] 下一頁
◎進入論壇網(wǎng)絡編程版塊參加討論
|