1

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

Folder 1
    Folder 2
        Folder 3
    Folder 4

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

选项1

当用户被授予对文件夹 1 的审核权限时，在文件夹 1 和用户 1 之间定义审核者关系。不会将其他关系添加到 db。

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

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

选项 2

当用户被授予对文件夹 1 的审核权限时，定义用户 1 和文件夹 1 之间的新关系，并在创建关系时定义所有子实体直至孙子的最大孙子实体，如果它被删除，则向下迭代图表以删除关系。如果我在建立这种关系后在文件夹 2 下添加一些东西，我只需将所有版主复制到新实体中。

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

想法

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

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

响应无液

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

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

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

没有也不会有很多版主需要访问他们审阅的项目的子项 - 如果有，对“UserModeratesParentOfThisFolder()”的调用是验证工作流程中的最后一次检查，因此不会有其他用例受到影响结果（我认为）。

同样值得考虑的是，您可以执行选项 3：维护“子文件夹与主持的父文件夹”关系，而不是在选项 2 中沿树复制主持人-文件夹关系。这样，您可以在两个查询中验证用户是否具有 mod 访问权限 - 1) 对包含 child_folder_mod_parent 关系的表，然后 2) 检查用户是否是任何返回的父文件夹的 mod。因此，即使有多个 mod，您复制这种关系的次数也少于选项 2。

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

我确实发现选项 2 和 3 很乱，恕我直言。#2 没有 #3 那么混乱，如果你需要的是纯粹的性能（真的会有那么多的 mod 活动吗？）那么你的选项 2 就足够了。从“结构”的角度来看，选项 1 是最简洁的，但也有其性能缺陷。您应该看到选项 1 对性能的影响有多大，以及是否比您需要实施选项 2 来解决它。我假设您将在底层数据库中使用等效的存储过程类型来实现选项 1。通过重复来回 SQL 到应用程序代码调用来执行此操作将是一个更大的性能打击。

我不认为会有大量的 mod 活动，而且我已经实施了选项 1，所以我想我会试一试，如果性能成为问题，我会牢记选项 2。不过，我对第三个选项很好奇……任何进一步的细节都会很棒。感谢您的帮助 ：）

4

1 回答 1

1

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

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

同样值得考虑的是，您可以执行选项 3：维护“子文件夹与主持父文件夹”的关系，而不是在选项 2 中沿树复制主持人-文件夹关系。这样，您可以在两个查询中验证用户是否具有 mod 访问权限 - 1）对包含 child_folder_mod_parent 关系的表，然后 2）检查用户是否是任何返回的父文件夹的 mod。因此，即使有多个 mod，您复制这种关系的次数也少于选项 2。

评论

我确实发现选项 2 和 3 很乱，恕我直言。#2 没有 #3 那么混乱，如果你需要的是纯粹的性能（真的会有那么多的 mod 活动吗？）那么你的选项 2 就足够了。从“结构”的角度来看，选项 1 是最简洁的，但也有其性能缺陷。您应该看到选项 1 对性能的影响有多大，以及是否比您需要实施选项 2 来解决它。我假设您将在底层数据库中使用等效的存储过程类型来实现选项 1。通过重复来回 SQL 到应用程序代码调用来执行此操作将是一个更大的性能打击。

编辑/回答 SB2055 的编辑：

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

在选项 1 中，您将使用查询/存储过程递归地增加文件夹到文件夹的关系，直到找到一个文件夹，其中 a) 有一个主持人，b) 主持人是当前用户。
在我的选项 3 中，这些递归将被降低（与选项 2 的目标一样），除了您在一个查询中直接知道任何文件夹的主持父（s）。在第二个查询中，您检查 if USER is in [list of mod's of folders from query 1]。
您将在此处更改的主要内容是，不是让每个文件夹都具有多个主持人关系（与选项 2 一样，这会导致大量添加记录），而是仅跟踪其自己的父级 OR 祖父级 OR 曾祖父级 OR... 文件夹被缓和。因此，如果您有 2 个版主和 4 个文件夹，结构如上：

  • 在选项2中，您将拥有关系...

    1. 用户 A 的文件夹 1 mod
    2. 用户 A 的文件夹 2 模组
    3. 用户 A 的文件夹 3 mod
    4. 用户 A 的文件夹 4 mod
    5. 用户 B 的文件夹 2 模组
    6. 用户 B 的文件夹 3 mod

  • 在选项 3 中，您将拥有

    1. 文件夹 1 - 无父/空（如果您愿意，空或无记录）
    2. 文件夹 2 由文件夹 1 修改
    3. 文件夹 3 由文件夹 1 修改
    4. 文件夹 3 由文件夹 2 修改
    5. 文件夹 1 的文件夹 4 模组

    （并且文件夹的 mod 关系将是）

    1. 用户 A 的文件夹 1 mod
    2. 用户 B 的文件夹 2 模组

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

  • 在选项 2 中几乎是[文件夹数x模组数] （因为有多个模组的文件夹）。
  • 在选项 3 中是 [文件夹数+调解文件夹数+模组数] （有点），因为您将拥有比模组更多的文件夹。

这将对数据库大小和选项 3与选项 2的其他附加好处产生差异：

  • db没有那么大
  • 文件夹数 >> 模组数（>>“远大于”）
  • 在选项 #3 中运行 2 个 sql 查询，性能命中并没有那么糟糕，而在 #2 中只运行 1 个查询；至少不像#1那样递归
  • 文件夹更改不需要您遍历整个子树来更新该树中的所有 mod 关系。仅需要更新“按文件夹修改”。
  • [错误，忽略，请参阅上面的文件夹 3] mod_by_Folder 可以与文件夹本身存储在同一个表中（parent_folder将存在，然后添加moderated_by_folder） - 尽管单独存储它更明智，但是...... （阅读下一个）
  • [错误，忽略，参见上面的文件夹 3]每个文件夹只有一个条目，用于管理它的文件夹（因此它可以存储在folders表中）
  • [正确]每个文件夹将只有它的 parent-moderated-folders 记录。（如果您只列出了一位主持的父母，您将需要像 opt #1 中那样的递归，但递归中的步骤更少。）

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

于 2013-06-28T06:15:54.547 回答