Question

我有一个可由用户审核的文件夹实体。文件夹可以包含其他文件夹。所以我可能有这样的结构：

Folder 1
    Folder 2
        Folder 3
    Folder 4

我必须决定如何为这个实体实施审核。我想出了两个选择：

选项1

当用户获得文件夹1的审核权限时，在文件夹1和用户1之间定义主持人关系。不会向db添加其他关系。

要确定用户是否可以审核文件夹3，我会检查并查看用户1是否是任何父文件夹的主持人。

这似乎减轻了在定义关系后处理文件夹1下的更新/移动实体/添加的一些复杂性，并且恢复关系意味着我只需要处理一个实体。

选项2

当用户获得文件夹1的审核权限时，在创建关系时，在用户1和文件夹1，和之间定义新关系，直到最大的孙子实体，以及它已被删除，迭代回到图表以删除关系。如果我在建立此关系后在文件夹2下添加了一些内容，我只需将所有版主复制到新实体中。

但是当我只需要显示用户正在审核的顶级文件夹时，我需要查询所有具有用户不适中的父文件夹的文件夹，而不是选项1，我只是查询任何文件夹用户正在审核的项目。

思想

我认为归结为确定用户是否会查询所有父项而不是查询子项...如果是，则选项1 似乎

两种方法都比另一方好吗？为什么？或者还有另一种方法比两种方法都好吗？我正在使用实体框架以防万一。

回应无液


在选项1中，当父文件夹带有时会发生什么   主持人 - 删除用户关系？子文件夹是否移动一个   升级？

从数据库中删除所有子项。


用户在需要确定的时间内执行操作的频率   他/她是该文件夹的mod？选项中创建的额外关系   2只有在有几个主持人和数千人的情况下才有用   子文件夹计算您希望它具有的性能。

没有也不会有很多主持人需要访问他们适度的项目的子项 - 如果有的话，调用“UserModeratesParentOfThisFolder（）”是验证工作流程中的最后一次检查，所以没有其他用例受到影响（我认为）。


另外值得考虑的是，而不是复制版主文件夹   在选项2中关闭树的关系，你可以做选项3：   维护'子文件夹到主持父文件夹'的关系。   这样，您可以在两个查询中验证具有mod访问权限的用户 -   1）到持有child_folder_mod_parent关系的表   然后2）检查用户是否是任何返回父项的mod   文件夹。所以，即使有多个mod，你也在复制它   关系少于选项2。

我不太明白这一点。这与选项1有什么不同？


我确实发现选项2和3凌乱，imho。＃2比＃3更乱，如果   它是你需要的纯粹性能（真的会有那么多mod吗？   活动？）然后您的选项2应该足够了。从'结构'   选择1是最好的，但有其缺点。您   应该看看选项1中的性能有多糟糕，如果是这样的话   比你需要实现选项2来解决它。一世   假设您将使用存储过程类型等效   选项1的底层数据库。重复执行   来回的SQL到应用程序代码调用将是一个更大的性能。

我认为不会有大量的mod活动，而且我已经实施了选项1，所以我认为如果性能成为一个问题，我会考虑一下并保留选项二。我很好奇第三个选项，但是任何进一步的细节都会很棒。谢谢你的帮助:)）

Answer 1

在选项1 中，当删除具有主持人 - 用户关系的父文件夹时会发生什么？子文件夹是否向上移动一级？

用户执行某项操作的频率，您需要确定他/她是否是该文件夹的mod？仅当有几个主持人和数千个子文件夹要根据您希望的性能进行计算时，在选项2 中创建的额外关系才有用。

另外值得考虑的是，您可以执行选项3 ，而不是将主持人 - 文件夹关系复制到选项2中的树上：将子文件夹维护到已审核的父文件夹＆＃39;关系。这样，您可以在两个查询中验证具有mod访问权限的用户 - 1）到保存child_folder_mod_parent关系的表，然后2）检查用户是否是任何返回的父文件夹的mod。所以，即使有多个mod，你也要复制这种关系 less 而不是选项2。

<强>评论

我确实发现选项2和3凌乱，imho。＃2比＃3更乱，如果你需要它的纯粹性能（真的会有那么多的mod活动吗？）那么你的选项2就足够了。来自一个＆＃39;结构＆＃39;选择1是最好的，但有其缺点。您应该看到选项1中的性能损失有多糟糕，以及它是否需要实现选项2来解决它。我假设您将在底层数据库中使用存储过程类型等效于选项1.通过重复来回的SQL到应用程序代码调用来执行它将是一个更大的性能。

编辑/回答以响应SB2055的编辑：

我不太明白这个 [选项3] 。这与选项1有什么不同？

在选项1中，您将使用查询/存储过程以递归方式提升文件夹到文件夹的关系，直到找到a）具有主持人并且b）该主持人是当前用户的文件夹。
在我的选项3中，这些递归将被降低（与选项2的目标一样），除了您在一个查询中直接知道任何文件夹的仲裁父级...在第二个查询中，您检查USER is in [list of mod's of folders from query 1]是否这里你要改变的主要是，不是每个文件夹都有多个版主关系（与选项2一样，这会导致很多添加的记录），这只跟踪它自己的父母或祖父母或者祖父母或者......文件夹。经过审核。因此，如果您有2个版主，其中包含4个如上所述的文件夹：

，您将拥有关系......
1. 用户A的mod 1文件夹
2. 用户A的mod 2文件夹
3. 用户A的mod 3文件夹
4. 用户A的mod 4文件夹
5. 用户B的文件夹2 mod
6. 用户B的文件夹3 mod
在选项3中，您将拥有
1. 文件夹1 - 没有父/空（如果您愿意，则为空或无记录）
2. Folder 2 mod by Folder 1
3. 文件夹3 mod by Folder 1
4. 文件夹3 mod by Folder 2
5. 文件夹4 mod by Folder 1

这两个在这个例子中可能看起来相同，但你的mod关系

几乎 [文件夹的数量 x mod的数量]（具有多个mod的文件夹的coz）。
是[文件夹的数量 + moderated_folders的数量 + mod的数量] （有点），因为你会有很多比mods更多的文件夹。

这会对db大小产生差异，而另一个则增加了选项3的优势与选项2：

db不大
文件夹数＆gt;＆gt; Mod的数量（>>远远大于＆＃39;）
在选项＃3中运行2个sql查询并没有那么差的性能，而不是＃2中的1个查询;至少不像＃1
文件夹更改不要求您浏览整个子树以更新该树中的所有mod关系。只有文件夹的＆＃39; mod＆＃39;需要更新。
[错误，忽略，请参阅上面的文件夹3] mod_by_Folder可以与文件夹本身存储在同一个表中（parent_folder将存在，然后添加moderated_by_folder） - 虽然单独存储更合理，但是...... （接下来阅读）
[错误，忽略，请参阅上面的文件夹3] 每个文件夹只有一个条目，由其审核的文件夹（因此它可以存储在folders表中）
[正确] 每个文件夹只包含其父级审核文件夹记录。（如果您只列出了一个经过审核的父级，则需要像在＃1中那样进行递归，但在递归时需要更少的步骤。）

编辑/ PS：在看到Folder-mod_by-Folder关系会发生链接之后，我不确定选项3是多么好。它是选项1和选项2之间的中间位置，用于维护文件夹和审核关系所需的添加记录，性能和事件触发器/查询（想象一个子文件夹中的树分割）。在查看数据库时，理解＃1和＃2也更简单，但没关系。并且＃3有2个依赖表来更新与mod关系相关的表，它不是更简单的解决方案，而不是＃2。

如何构建级联属性 - 仅适用于父元素或所有子元素？

1 个答案: