遞歸在這種情況下的最優解決方案？

Question

我對此感到頭疼。我正在構建一個可以處理大量項目，組和文件引用的系統。 請看看這個：

用戶應該能夠創建項目無限多，組的無限數量和附加文件引用無限數量的 - 就像一個普通的PC文件結構可與驅動器號，文件夾和文件。

所提到的所有元素的駐留在MySQL數據庫中。不過，我不知道這（見下文）是構建了整個事情的最佳方式：

正如你所看到的，它包含了所謂的「外部參照」一個實體，包含的項目和團體。這些行指向內部，可能使得它在檢索數據時執行遞歸調用是理想的。

不同的方法可以是爲項目創建1個實體，爲組創建1個實體，爲文件引用創建1個實體...以及1個幫助實體，將三個實體連接在一起，還包含「父」值（類似於第一種解決方案）是指上層元組以創建層次結構。

如果你要建立一個類似的項目，你會怎麼做？

Answer 1

您碰到了MySQL最有名的限制之一：使用所謂的遞歸查詢（PostgreSQL）或CTE查詢（Oracle）的能力。有一些可能的解決方法，但考慮到這種需求的項目，您可能會遭受很多其他衆所周知的MySQL限制。即使SQLLite在這個問題上會更有用（除了一個併發用戶限制）。

DBIx ::類有一些組件，幫助您規避這個MySQL限制，搜索嵌套樹，有序樹，與遞歸查詢 ... [DBIx::Class::Tree::NestedSet][1]

您將需要類似的支持： 7.8. WITH Queries (Common Table Expressions)，MySQL不提供給你。

Answer 2

您的結構很好 - 由於您正在構建一棵樹，而不是一般圖，因此不需要將實體連接在一起的單獨表。我會把項目放到他們自己的桌子上，因爲他們似乎站在自己的桌子上，除非你必須支持項目之間的層次結構。

但是，鑑於您的RDBMS是MySQL，您在構建遞歸查詢時會遇到問題。例如，請嘗試考慮一個查詢，該查詢將爲您提供與1（即項目）的xfer_id相關的所有文件。沒有任何文件與該ID綁定，因此您需要找到您的一級組，然後找到您的二級組，然後將文件綁定到它們。由於您的組可以嵌套在任意級別，所以您的查詢也必須遞歸。

雖然你當然可以做到，it is currently not simple, and requires writing stored procedures。這種情況的一種常見方法是在RDBMS的幫助下在內存中構建樹。訣竅是存儲每個組中的頂級項目的id，即

xfer_id xfer_fk xfer_top 
------- ------- -------- 
    1  -  1 
    2  1  1 
    3  1  1 
    4  3  1 
    5  3  1 

現在有了條件WHERE xfer_top=...查詢會給你所有的個人「零件」，它可以在內存中進行組合，而無需派遣內存中的整個表。