我们公司在从单个用户应用程序迁移到多个用户应用程序时遇到问题。我们的设置是用户拥有一个产品，并且所有权是通过外键进行的。由于他们拥有产品，因此他们有权在产品上执行所有功能。如果您不拥有产品且不是管理员，则您无法访问产品或其任何功能。
现在，我们正在尝试打开对产品的访问权限，以及与各自所有者一起分组的其他用户进行协作。包括所有者在内的这些其他用户可能基于一组权限具有有限的功能。权限的范围设计基于
这些关系已经实施，但是在系统基于关系进行大量计算的情况下出现了问题。例如获取用户对产品集合的权限会严重影响性能。此外，我们系统的灵活性受到新关系和抽象的限制。
数据库方面，我认为关系2是可用于表达所有关系行为的基本块，以及我们公司将被要求分层的任何未来抽象。
我在这种思路中是否正确？或者我们现在正走在正确的轨道上？任何有用的输入将不胜感激。
相关技术已被标记。
答案 0 :(得分：0)
严格规范化的关系数据库在这样的应用程序中可能成为瓶颈。我还没有看到解决方案，但如果你考虑在规范化数据库中禁止的表，你可以加快速度，就像某种缓存一样。
我的方法是使用包含实际数据的严格规范化的DB部分和充当缓存的非规范化部分......这两部分之间的更新是一种方式：从规范化部分到缓存（以防万一）如果数据中出现不一致的数据/异常，则可以重建缓存）
优点是：每个用户的权限可以聚合（甚至可以作为二进制对象），并且每个用户/每个产品/等被提取为一行，只要权限来自缓存...取决于在用例上，这可以非常快
缺点是：缓存数据的更新更复杂：您必须更新普通数据库，然后必须更新缓存，否则缓存将无法显示更新，直到重新生成...这是如果您的权限不是每2秒更新一次就没什么大问题
plus：你必须实现和维护缓存以及使用它的应用程序......
所以一个警告：即使这个可以（==并不保证在每种情况下都是如此）非常快，只要还有其他选项，就不应该使用这种方法。 （你应该尽可能避免破坏规范化;数据库是否正确编入索引？是否可以在其他地方设置这样的缓存，即某个服务应用程序？）