我有一个包含角色的表。可以将许多用户分配到角色。可以将权限分配给角色，并使用权限授予该角色的所有用户。
当我为拥有500人的角色分配权限时，我已经有效地创建了500个权限分配。
使用分配给角色的每个权限，我指定在确定具有该角色的每个人具有哪种类型的权限访问时必须进行的复杂计算。例如，如果我为“ACCOUNTANT”角色分配“READ_EMAIL”权限，那么在我这样做时，我还包含一个变量，用于指定允许哪些邮箱类型，因为有多种邮箱类型，而会计师应该只有访问他们中的某一组。
因此，当我想知道哪些个人可以访问哪些特定邮箱时，我不仅要加入我的权限，角色和用户表，而且我需要查找一些因为空间难以解释的原因这是耗时的，不能更快。
我遇到的问题是，当我在视图中公开所有计算的权限分配（加入所有这些表+进行复杂，耗时的计算）时，需要很长时间。
在我看来，我可以简单地创建一个用户角色权限表，该表通过将用户分配给角色或通过为角色分配权限而激活的触发器填充。每当为角色分配权限时，它将为具有该角色的每个人插入记录，并在那时进行复杂查找，将500条记录放入该表中。每当将用户分配给角色时，它将生成任何权限+复杂查找。这个表中有外键到角色分配表和权限分配表，带有级联删除。
角色分配的许可很少，所以如果速度大大减慢就没问题。对我的表的访问率为99.99999％是SELECT。
这种方法有什么缺点吗？我需要实时数据。我只是在设计我自己的on-commit物化视图吗？还有其他建议吗？
答案 0 :(得分：2)
听起来你正在设计自己的on-commit物化视图。您是否有理由不能在此处使用on-commit物化视图来缓存结果？
刷新物化视图失败会导致事务的提交操作失败，从而导致回滚。因此，数据和物化视图实际上不可能不同步。基于触发器的解决方案肯定更有可能最终出现错误（特别是如果同时在多个会话中进行了更改）。我更愿意将同步逻辑写入Oracle。