我有一个可以由用户调节的文件夹实体。文件夹可以包含其他文件夹。所以我可以有一个这样的结构:
Folder 1
Folder 2
Folder 3
Folder 4
我必须决定如何为这个实体实现适度。我想到了两个选项:
选项1
当用户对文件夹1具有审核权限时，定义文件夹1和用户1之间的审核关系。没有其他关系被添加到数据库中。
要确定用户是否可以调节文件夹3，我检查用户1是否为任何父文件夹的主持人。
这似乎减轻了在关系定义后在文件夹1下处理更新/移动实体/添加的一些复杂性，并且恢复关系意味着我只需要处理一个实体。
选项2
当用户被授予对文件夹1的调节权限时，在user1和文件夹1之间定义一个新的关系，当关系创建时，和所有子实体直到最大的孙子，如果它被删除，则向下迭代图以删除该关系。如果我在建立这种关系后在文件夹2下添加一些内容，我只需将所有版主复制到新实体中。
但是，当我只需要显示用户正在主持的顶级文件夹时，我需要查询所有具有用户未主持的父文件夹的文件夹，而不是选项1，在选项1中，我只查询用户正在主持的任何项目。
我认为可以归结为确定用户是否会查询所有父项而不是查询子项…如果是这样，那么选项1似乎更好。但我不确定。
哪一种方法比另一种好?为什么?或者有没有比这两种方法都更好的方法?我使用实体框架的情况下，它的问题。
响应anoid
在选项1中，当父文件夹带有版主——用户关系被删除了?子文件夹移动一个吗水平了?
从数据库中删除所有子节点。
用户执行操作的频率需要确定是否他/她是那个文件夹的mod ?选项中创建的额外关系只有当有几个版主和数千个版主时，2才有用要计算的子文件夹的值
没有，也不会有很多主持人需要访问他们主持的项目的子项目-如果有，调用"UserModeratesParentOfThisFolder()"是验证工作流中的最后一次检查，所以没有其他用例因此受到影响(我认为)。
也是值得考虑的，而不是复制moderator文件夹选择2的关系，你可以选择3维持"子文件夹到缓和的父文件夹"的关系。这样，您就可以在两个查询中验证具有mod访问权限的用户1)到保存child_folder_mod_parent关系和的表然后2)检查用户是否是任何返回父节点的mod文件夹。所以即使有多个模组，你也是在复制这个关系小于选项2
我不太明白这个。这和选项1有什么不同?
我觉得选项2和3很乱，恕我直言。#2比#3更整洁，如果您需要的是纯粹的性能(真的会有那么多mod吗?活动?)，那么选项2就足够了。从一个"结构"从角度来看，选项1是最简洁的，但也有缺点。你应该看看选项1对性能的影响有多严重，如果是这样的话比您需要实现选项2来解决它要多得多。我的存储过程类型等效选项1的底层数据库。反复练习来回SQL到应用程序代码调用将是一个更大的命中率。
我不认为会有大量的mod活动，我已经实现了选项1，所以我想我会给它一个尝试，并保留选项2，如果性能成为一个问题。我对第三种选择很好奇……任何进一步的细节都会很棒。谢谢你的帮助:)
Inoption 1，当具有版主-用户关系的父文件夹被删除时会发生什么?子文件夹向上移动一层吗?
用户多久执行一次操作，您需要确定他/她是否是该文件夹的mod ?在选项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)…在一个查询中。在第二个查询中，您检查是否USER is in [list of mod's of folders from query 1].
您将在这里更改的主要内容是，而不是让每个文件夹具有多个版主关系(如选项2，这会导致大量添加的记录)，这只跟踪其自己的父或祖父母或曾祖父或…被审核的文件夹。如果你有2个版主和4个文件夹，结构和上面一样:
在选项2中，您将拥有关系…
- 文件夹1 mod由用户A
- 文件夹2 mod由用户A
- 文件夹3 mod由用户A
- 文件夹4 mod由用户A
- 文件夹2由用户B mod
- 文件夹3由用户B mod
在选项3中，您将使用
- 文件夹1 -无父/空(空或无记录，如果你喜欢)
- 文件夹2由文件夹1 mod
- Folder 3 mod by Folder 1
- Folder 3 mod by Folder 2
- Folder 4 mod by Folder 1
(文件夹的mod关系为)
- 文件夹1 mod由用户A
- 文件夹2由用户B mod
这两个在这个例子中看起来是相等的但是你的mod关系
- 选项2几乎[文件夹数xmod的数量](因为文件夹中有多个mod)。 选项3中的
- 为[文件夹数+]modated_folders数目+(sort of)因为你会有比mod更多的文件夹。
这将对数据库大小和选项3
的其他附加好处产生影响。Vs选项2:- db not as big
- folder number>> Mods number (
>>'much大于') - 在选项#3中运行2个sql查询，而不是在#2中运行1个查询。至少不像#1 那样递归
- 文件夹的更改不需要您遍历整个子树来更新该树中的所有mod关系。只有"mod by Folder"需要更新。
- [错误，忽略，参见上面的文件夹3]mod_by_Folder可以存储在与文件夹本身相同的表中(
parent_folder将存在，然后添加moderated_by_folder) -虽然单独存储更明智，但是…(下) - [错误，忽略，参见上面的文件夹3]每个文件夹只有一个条目，该文件夹由其调节(因此它可以存储在
folders表中) - [CORRECT]每个文件夹只有它的父文件夹记录。(如果只列出一个缓和的父级，则需要像opt #1那样的递归，但递归中的步骤更少。)
编辑/PS:看到链接，将发生与文件夹mod_by文件夹的关系，我不确定选项3是所有的伟大。它介于选项1和选项2之间，需要添加记录、性能和事件触发器/查询来维护文件夹和调节关系(想象一个树在其中一个子文件夹中分裂)。在查看数据库时，也更容易理解第1条和第2条，但这没关系。#3有2个与mod关系相关的依赖表要更新，这不是一个比#2更简单的解决方案。