其他实体的多用户权限答案

【问题标题】：Multiple User Permissions for other Entities其他实体的多用户权限
【发布时间】：2011-05-25 22:07:31
【问题描述】：

我们公司在从单个用户应用程序迁移到多个用户应用程序时遇到问题。我们的设置是用户将拥有一个产品，并且所有权是通过一个外键。由于他们拥有产品，他们将有权执行产品的所有功能。如果您不拥有该产品并且不是管理员，则您无法访问该产品或其任何功能。

现在，我们正尝试向已与各自所有者分组的其他用户开放对产品的访问权限，以进行协作。包括所有者在内的这些其他用户可能具有基于一组权限的有限功能。权限范围被设计为基于

这些关系已经实现，但是在系统基于关系进行大量计算时出现了问题。例如获得用户对产品集合的权限会严重影响性能。此外，我们系统的灵活性也受到新关系和抽象的限制。

就数据库而言，我认为关系 2 是基本块，可用于表达所有关系的行为以及我们公司将被要求在其上分层的任何未来抽象。

我的这种思路正确吗？还是我们现在走在正确的轨道上？任何有用的意见将不胜感激。

标记了相关技术。

【问题讨论】：

【解决方案1】：

对于此类应用程序，严格规范化的关系数据库可能会成为瓶颈。我还没有看到解决方案，但是如果您将规范化数据库中被禁止的表视为某种缓存，则可以加快速度。

我的方法是拥有一个包含实际数据的严格规范化的 DB 部分和一个充当缓存的非规范化部分......这两个部分之间的更新是一种方式：从规范化部分到缓存（以防万一cahce中的不一致数据/异常，可以重建缓存）

优点是：您的每个用户的权限可以聚合（甚至可以作为二进制对象）并作为每个用户/每个产品/等的单行获取，只要权限来自缓存...取决于在用例上，这可能非常快

缺点是：对缓存数据的更新更复杂：您必须更新普通数据库，然后您必须更新缓存，否则您的更新将不可见，直到它重新生成...这是如果您的权限不是每 2 秒更新一次，那没有什么大问题

另外：您必须实现和维护缓存以及使用此缓存的应用程序...

所以有一个警告：即使这个可以（== 不能保证在每种情况下都非常快），只要还有其他选项，您也不应该使用这种方法。（您应该尽可能避免破坏规范化；数据库是否正确编入索引？可以在其他地方设置这样的缓存吗，即某处的服务应用程序？）

【讨论】：

真正关心的不是速度，更多的是当前设置的规范化和不灵活。我们设计了数据库的基础以反映更抽象的逻辑（范围 3 和 4）。我现在坚持当前的实现，但下次我被要求设计这样的系统时，我会记住这一点。谢谢你的回答。