數據庫結構和查詢層次數據和數據

Question

可能重複的樹木：
What is the most efficient/elegant way to parse a flat table into a tree?

這我發現相當棘手的，並希望對此事的一些看法。 我想存儲分層數據（樹狀）與未知數量的層次和分支。我希望能夠隨時添加新的和刪除任何內容。

由於龐大的用戶羣，我需要能夠從層次結構中的任何節點一次查詢所有子級ID的查詢。

讓我們假設一個網站的家庭社交化和更新他們的地位，如Facebook在任何時候你可以查看家庭成員「牆」，其中還包括所有最近的狀態更新下面的人他們按照時間順序排列在層次結構中。

很顯然，一旦你擁有了這個家庭成員身份證的數組，這個家庭成員節點的子節點，獲取帖子在循環中很容易。

讓我們的例子簡單的表結構：

id | parentId | name 
________________________ 

1 | NULL | John 
2 |  1  | Peter 
3 |  1  | Bob 
4 |  3  | Emma 
5 |  2  | Sam 
6 |  4  | Gill 

等....你的想法。

我需要能夠做到以上這樣的東西，除非你認爲結構需要適應。我已閱讀mySql nested set model。 這看起來很複雜，如果有些東西不能正確更新並且會把所有東西搞砸，這可能是不可靠的。

我習慣於使用php和mysql，但一直在讀cassandra和節儉。不知道這是否會更容易？

Answer 1

已經有很好的方法比您提出的解決方案更簡單。

下面是一些解釋如何做到這一點的鏈接（我們自己使用這個和你描述的很相似的問題，它工作的很好）。

• Managing Hierarchical Data in MySQL（從MySQL）
• Storing Hierarchical Data in a Database（從Sitepoint，但更清楚的解釋，我認爲）

這使得插入/更新更加複雜，但選擇所述樹結構的部分遠更快（只有一個查詢）。它允許在一個查詢中查找任何給定節點的所有子節點，並用一個查詢查找給定節點的所有祖先。

Answer 2

所以我想我已經想出了一個想法。

我反對嵌套集模型的原因是因爲它似乎仍然不是最好的方法，也不會是理想的性能解決方案。

我將介紹一個我一直在考慮的建議解決方案。 這個概念意味着創建一個hierarchal map表來跟蹤每個家庭成員/節點之間的所有關係。

它的工作方式是：

使用該映射表結構：

id | fMemberId | parentid 
===================================== 
1 |  3  |  2 
2 |  4  |  3 
3 |  4  |  2 

1）作爲一個新的家庭成員作爲父母的孩子，我們會採取建立父母ID並在我們的家庭成員表中創建一個新行，並設置父級ID以供未來額外的使用和功能使用。

2）在創建該行時，我們將創建新行，併爲新家族成員創建具有所有父ID的新行。

這樣做的一種快速方法是從新家庭成員中獲取父ID，然後對map表執行查詢，以查找家族成員ID與新家庭成員父ID相同的所有行然後將數組存儲在隨後的父ID中，並在map表中與新的家庭成員ID一起存儲。 這則僅需要一個SQL查詢搶佔了所有父ID的添加他們，而不是基於節點的數量大量查詢

當我們觀察一個家庭成員，這意味着飼料的職位，我們將能夠查詢數據庫中的map表中的行，以獲取當前系列成員的所有子代碼，然後在其他表中查找發佈數據。

主要的折衷是這類系統所需的潛在存儲量。 但是我相信閱讀速度會更快，因爲沒有條件SQL語句，並且也可能以這種方式快速寫入數據庫。

我們可以通過使用InnoDB的集羣ID分配一個初始的家族ID索引並根據家族ID創建一個帶有「下一個家庭成員ID」的新表來克服這個問題。

另外可靠性，如果一行沒有被寫入，就很容易添加它。它可以防止爲了創建成員而不斷地編輯行。

你對此有何看法？

到目前爲止，這在我看來似乎是一個好方法。花了很多心思去到這裏。我也相信它可能會隨着時間的推移而得到改進，並且能夠存儲每個成員的id數組而不是所有的成員。仍然試圖解決這個問題！

Answer 3

是的，你的解決方案被稱爲傳遞閉包。我已經寫之前：

• What is the most efficient/elegant way to parse a flat table into a tree?
• Models for Hierarchical Data

您還需要零長度的路徑，例如2-2，3-3，4-4。