Quels sont les inconvénients de maintenir une table d'enregistrements calculés avec des déclencheurs et des contraintes FK?

Question

J'ai une table contenant des rôles. De nombreux utilisateurs peuvent être affectés à un rôle. Les autorisations peuvent être attribuées à un rôle, accordant à tous les utilisateurs ce rôle avec l'autorisation.

Lorsque j'attribue une autorisation à un rôle de 500 personnes, j'ai créé 500 attributions d'autorisations.

Avec chaque autorisation affectée à un rôle, je spécifie un calcul complexe qui doit avoir lieu lors de la détermination du type d'autorisation d'accès de chaque individu ayant ce rôle. Par exemple, si j'attribue une autorisation "READ_EMAIL" à un rôle "ACCOUNTANT", au moment où je le fais, j'inclue également une variable qui spécifie quels types de boîte aux lettres sont autorisés, car il existe plusieurs types de boîte aux lettres. l'accès à un certain groupe d'entre eux. Donc, quand je veux savoir quelles personnes ont accès aux boîtes aux lettres spécifiques, je dois non seulement joindre mes permissions, rôles et tables d'utilisateurs, mais je dois faire une recherche pour des raisons qui sont difficiles à expliquer dans le l'espace ici prend du temps et ne peut pas être rendu plus vite. Le problème que je rencontre est que lorsque j'expose toutes les affectations d'autorisations calculées dans une vue (joignant toutes ces tables + effectuant un calcul complexe et prenant beaucoup de temps), cela prend beaucoup de temps. Il m'est apparu que je pouvais simplement créer une table d'autorisation de rôle d'utilisateur qui est remplie via des déclencheurs activés en affectant un utilisateur à un rôle ou en attribuant une permission à un rôle. Chaque fois qu'une permission est assignée à un rôle, il insère un enregistrement pour chaque individu ayant ce rôle et effectue la recherche complexe à ce moment-là, en plaçant 500 enregistrements dans cette table. Chaque fois qu'un utilisateur est assigné à un rôle, il génère des autorisations + des recherches complexes. Il y aurait des clés étrangères de cette table à la table d'attribution de rôle et aux tables d'affectation d'autorisation, avec des suppressions en cascade.

La permission d'attribuer un rôle est rare, donc c'est bien si cela est considérablement ralenti. 99,99999% de l'accès à mes tables est SELECT.

Des inconvénients à cette méthode? J'ai besoin de données en temps réel. Suis-je en train d'élaborer ma propre vue matérialisée? D'autres suggestions?

Answer 1

Il semble que vous construisiez votre propre vue matérialisée. Y a-t-il une raison pour laquelle vous ne pouvez pas simplement utiliser une vue matérialisée sur-engagement ici pour mettre en cache les résultats?

Un échec d'actualisation de la vue matérialisée entraînerait l'échec de l'opération de validation de la transaction, ce qui entraînerait une annulation. Il n'est donc pas vraiment possible que les données et la vue matérialisée soient désynchronisées. Il est certainement beaucoup plus probable qu'une solution basée sur un déclencheur aboutisse à des bogues (en particulier si des modifications sont apportées simultanément à plusieurs sessions). Je préfère laisser l'écriture de la logique de synchronisation à Oracle.