如何构建级联属性 - 仅应用于父元素还是应用于所有子元素？

Question

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

Folder 1 
    Folder 2 
     Folder 3 
    Folder 4 

我必须决定如何执行此实体的审核。我想出了两个选项：

选项1

当用户被赋予主持权到文件夹1，定义文件夹1和用户1.无其他关系之间的关系主持人加入到D b。

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

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

选项2

当用户被赋予适度的权限文件夹1，定义用户1和文件夹1，和所有子实体下到盛大的孙子之间的新关系时，关系是创建，如果它被删除，则向下迭代图表以删除关系。如果我在文件夹2下添加了一些关系后，我只需将所有版主复制到新实体中。

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

思考

我认为它归结为确定是否用户将查询所有父项比他们更会查询子项...如果是这样，那么选项1 似乎更好。但我不确定。

要么比其他方法更好？为什么？还是有另一种方法比两者都好？我使用实体框架以防万一。

针对无液

在选项1中，当与 主持人父文件夹会发生什么 - 用户关系被删除？儿童文件夹是否会将一个 级别向上移动？

所有孩子都从数据库中删除。

用户多长时间执行一次操作，您需要确定他/她是否是该文件夹的模组？在选项 2中创建的额外关系可能仅在有几个主持人和数千个子文件夹要计算您希望具有的性能时才有用。

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

也是值得考虑的，而不是在复制选项2主持人文件夹 关系下的树，你可以做选择3： 维持“子文件夹，以缓和父文件夹”的关系。 这样，您可以验证用户在两个查询中具有mod访问权限 - 1）到保存child_folder_mod_parent关系和 的表格，然后2）检查用户是否是任何返回的父文件夹的模块。所以即使有多个mod，你也在复制这个 的关系少于选项2.

我不太明白这一点。这和方案1有什么不同？

我找到选项2和3凌乱，恕我直言。 ＃2不如＃3那么混乱，如果你需要纯粹的性能（如果真的有那么多的mod 活动？），那么你的选项2就足够了。从'结构' 的角度来看，选项1是最好的，但有其缺点。您应该看到选项1中的性能命中有多糟糕，并且如果它如此 比您需要实现选项2来解决该问题多得多。 I 假设您将在 底层数据库中使用与存储过程等效的选项1.通过重复执行 来回应用程序代码调用的SQL将会产生更大的性能提升。

我不认为会有一吨国防部的活动，我已经实现的选项1，所以我想我给它一个去，并保持选项两记应该表现成为一个问题。我很好奇第三个选项，虽然...任何进一步的细节都会很棒。谢谢你的帮助:)

Answer 1

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

用户在需要确定他/她是否是该文件夹的模块时执行某个操作的频率如何？在选项2中创建的额外关系只有在有多个主持人和数千个子文件夹才能计算出您想要的性能时才有用。

同样值得考虑的是，不是在选项2中的树中复制主持人 - 文件夹关系，而是可以执行选项3：将“子文件夹保持为主文件夹”关系。这样，您可以验证用户在两个查询中具有mod访问权 - 1）保存child_folder_mod_parent关系的表，然后2）检查用户是否是任何返回的父文件夹的Mod。所以即使有多个mod，你也在复制这个关系少于比在选项2中。

评论

我确实发现选项2和3凌乱，恕我直言。 ＃2不如＃3杂乱，如果它是你需要的纯粹性能（真的会有那么多的mod活动？），那么你的选项2就足够了。从“结构”的角度来看，选项1是最好的，但有其缺点。您应该看到选项1中的性能影响有多糟糕，并且如果它比您需要实施选项2来解决这个问题多得多。我假设你会在底层数据库中使用一个存储过程类型的等价物来实现选项1.通过对应用程序代码调用重复来回的SQL来做到这一点将是一个更大的性能指标。

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

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

在方案1中，您将使用查询（收费）/存储过程递归上文件夹到文件夹关系，直到找到一）有一个主持人的文件夹以及b）主持人是当前用户。
在我的选项3中，这些递归将被降低（如选项2的目标），除了您直接知道任何文件夹的父母（一个或多个）在一个查询中。在第二个查询中，您检查是否USER is in [list of mod's of folders from query 1]。
你将在这里改变的主要是，而不是每个文件夹有多个主持人关系（与选项2，这会导致大量添加记录），这只会跟踪其自己的父OR祖父母或greatgranparent OR ...经过审核的文件夹。所以，如果你有2个主持人与4个文件夹结构如上：

• 在选项2，你会有关系...

  1. 文件夹1个模由用户A
  2. 文件夹2模由用户A
  3. 文件夹3模由用户A
  4. 文件夹4 MOD由用户A
  5. 文件夹2模由用户B
  6. 文件夹3由用户B

• 在选项3国防部，你会

  1. 文件夹1 - 无父/空（null或如果你喜欢没有记录）
  2. 文件夹2模按文件夹1
  3. 文件夹3 MOD按文件夹1
  4. 文件夹3 MOD按文件夹2
  5. 文件夹4由文件夹1

  MOD（和文件夹的MOD关系将是）

  1. 文件夹1通过用户B的用户国防部一个
  2. 文件夹2模

这两个看起来在这个例子中平等的，但你的MOD关系

• 在选项2 几乎 [文件夹数量x mods数量]（多于一个mod的文件夹）。
• 中选择3 [文件夹的数量+数moderated_folders的+数量的mods] （在某种程度上）因为你会比MODS更多的文件夹。

这将使差异的分贝大小，选择3的其他添加好处VS选项2：

• 分贝不一样大
• 数量的文件夹>> MODS的数（>>'远远大于'）
• 在选项＃3中运行2个sql查询并没有那么差的perf命中，而不是在＃2中只有1个查询;至少不会像＃1一样递归。
• 文件夹更改不要求您通过整个子树来更新该树中的所有mod关系。只有'按文件夹修改'需要更新。
• [错了，忽略了，请参阅文件夹3以上]的mod_by_Folder可以存储在同一个表文件夹本身（parent_folder将存在，再加入moderated_by_folder） - 尽管它更明智的存储分开，但.. 。（读下一个）
• [WRONG，忽略，见上文文件夹3]每个文件夹仅具有一个条目为哪个文件夹它是由（以便它可以存储在folders表）主持
• [CORRECT]每个文件夹只有其父文件夹文件夹记录。 （如果你只列出了一个主持人，你需要在opt＃1中递归，但在递归中需要更少的步骤）。

Edit/PS：在看到Folder-mod_by-文件夹关系，我不确定选项3是多么伟大。这是选择1和选项2之间的中间方式，用于维护文件夹和管理关系（想象树分裂在其中一个子文件夹中）所需的添加记录，性能和事件触发器/查询。在查看数据库时，理解＃1和＃2也更简单，但没关系。并且＃3具有2个相关表来更新与mod关系相关的数据，这不是比＃2更简单的解决方案解决方案。