verrouiller vue pour être ineditable

Question

Je construis une base de données qui contient des données publiques, privées (limitées à internes) et confidentielles (limitées à très peu). Il a des exigences très spécifiques que la sécurité des données est gérée du côté de la base de données, mais je travaille dans un environnement où je n'ai pas le contrôle direct des permissions, et les demandes pour les changer prendront du temps (2-3 journées).

J'ai donc créé une structure qui devrait répondre à nos besoins sans nécessiter beaucoup de permission. J'ai créé deux bases de données sur le même serveur, l'une interne, dont les tables ne peuvent être éditées que par certains utilisateurs dans certains sous-réseaux de notre réseau. La seconde est la base de données publique où, à l'aide d'un compte administrateur, je crée des vues limitées aux champs publics des tables de la base de données interne pour exposer les données publiques et cela semble bien fonctionner. Cependant, les données ne doivent circuler que dans un sens et les vues ne doivent pas pouvoir écrire dans les tables source. Et je ne peux pas simplement verrouiller la base de données publique pour qu'elle soit seulement SELECTable puisque la base de données publique est utilisée pour diverses tâches de notre site Web public. J'ai donc besoin de créer des vues pour limiter l'accès de certains scripts à certains champs d'une table. Je dois m'assurer que ces vues ne peuvent pas insérer, mettre à jour ou supprimer des données dans la table source. Pour créer la vue que j'utilise:

CREATE ALGORITHM = UNDEFINED 
VIEW `table_view` AS 
    SELECT * 
    FROM `table` 

En regardant la documentation afin d'éviter des mises à jour de la vue a besoin d'avoir des données agrégées, des sous-requêtes dans la clause WHERE et ALGORITHME = TEMPTABLE. J'irais avec TEMPTABLE, mais le manuel n'est pas clair si cela aurait un impact sur la performance. Dans un paragraphe the manual états:

Il préfère MERGE sur TEMPTABLE si possible, parce que MERGE est généralement plus efficace

Alors déclare immédiatement:

Une raison de choisir TEMPTABLE explicitement est que les verrous peuvent être publié sur les tables sous-jacentes après la table temporaire a été créée et avant qu'il soit utilisé pour terminer le traitement de l'instruction. Cela peut entraîner une libération plus rapide du verrou que l'algorithme MERGE de sorte que les autres clients qui utilisent la vue ne soient pas bloqués aussi longtemps que .

Les vues vont être interrogés sur la charge de page pour générer le contenu de la page, fusionneriez encore more efficient ou me servir le temps de verrouillage inférieur mieux? Et non, la gestion de ces autorisations par compte n'est pas vraiment une option en raison de l'impossibilité d'accorder des autorisations sur des champs individuels pour répondre aux exigences légales de confidentialité. Pour y répondre, il faudrait fragmenter chaque table en 2 ou 3 tables contenant des champs avec une confidentialité homogène.

L'algorithme doit-il être NON DÉFINI ou TEMPTABLE ou existe-t-il un autre paramètre dans la définition de la vue qui verrouillera la vue? Et quels sont les effets de performance que je vais expérimenter. Aussi, si je fais quelque chose pour le forcer à ne pas être éditable, comme inclure AYANT 1 pour en faire une fonction d'agrégat le force à être TEMPTABLE et le choix de l'algorithme discutable.

Answer 1

Je me demande pourquoi vous ne vous contentez pas de verrouiller grants to the account(s) being used to not have DELETE, INSERT or UPDATE.

MySQL ne semble pas soutenir les rôles, où j'aurais défini un rôle sans ces subventions & simplement associées au compte (s) avec ce rôle - dommage ...