2009-08-07 34 views

回答

3

是的,當您對分層數據使用實體化路徑或嵌套集解決方案時,您必須自己在DAL中執行數據完整性。

鄰接列表支持引用完整性,對於我稱之爲「Closure Table」(Tropashko稱此設計爲「傳遞閉包關係」)的設計也是如此。

+0

感謝您的信息,比爾。 – hyperslug 2009-08-07 08:38:17

+0

這裏是關於傳遞閉包解決方案的文章:http://www.codeproject.com/KB/database/Modeling_DAGs_on_SQL_DBs.aspx @Bill Karwin:你在OLTP /交互式場景中使用「閉合表」部署了多大數據集而沒有達到性能插入問題? – nawroth 2009-08-07 11:59:31

+0

@nawroth:只有樹上數千個節點的順序,這麼好。如果你需要表現很深的樹木,你會得到很多行。如果你需要代表許多淺層樹木,那就更加謙虛。 – 2009-08-07 14:32:52

1

在物化路徑模型中,您可以使用任意字符串(也許unicode字符串以允許超過256個子元素)而不是形式爲「x.y.z」的特殊字符串。父母的ID是直接子女的ID,最後一個字符被刪除。您可以輕鬆地檢查約束強制執行這個喜歡(我的例子中的PostgreSQL作品)

check(parent_id = substring(id from 1 for char_length(id)-1)), 

你create table命令中。如果你堅持使用「x.y.z」形式的字符串,你將不得不使用正則表達式,但我猜想可能找到相應的檢查約束。

+0

如果您想強制根具有char_length(id)= 1,那麼您可以額外將約束檢查((parent_id爲null)或(char_length(id)= 1))添加到表定義中。 – Whoever 2009-08-07 12:08:53

3

Vadim Tropashko在該文章中提出的「物化路徑」,將秩序的概念引入到關係中(「瓊斯是第二個成員」)。

「物化路徑」僅僅是傳遞閉包的「某種形式的物化視圖」,因此會遭受與任何其他「物化視圖」完全相同的問題,除了事物在算法上由於參與封閉。

當封閉約束髮揮作用時,SQL幾乎完全無能爲力。 (意思是說,SQL要求你自己做所有事情。)這是RM顯示其幾乎無限制的最大功能的領域之一,但是SQL失敗了,而且大多數人誤認爲這是一種恥辱爲關係。

(@Bill Karwin:我希望能夠給你+1關於樹深度和性能結果之間的關係的評論。沒有已知的算法來計算性能良好的閉包在用「瘋狂」深度樹木的情況。這是一個算法的問題,而不是一個SQL也不是關係之一。)

編輯

是,RM =關係模型

+0

RM =關係模型? – hyperslug 2009-08-07 21:17:52

+1

+1是的,物化路徑是非規範化的一個例子。它對某些類型的查詢有一定的效率優勢,但它會犧牲RM的好處,例如引用完整性。 – 2009-08-07 21:43:46

+0

順便說一句,你可以將鼠標懸停在評論左側的不可見的upvote箭頭上,並給予評論一點支持。不過,這並不代表重要的意義。 – 2009-08-07 21:44:44