递归在这种情况下的最优解决方案？

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=...查询会给你所有的个人“零件”，它可以在内存中进行组合，而无需派遣内存中的整个表。