Discussion :

[laurent1133]

Est ce une bonne stratégie d'utiliser 200 vues ou plus dans une base ?

[Artemus24]

Salut Laurent1133.

D'utiliser des view, oui, c'est une bonne stratégie.
Sur le nombre de view, il est difficile de répondre si l'on ignore de quoi il s'agit.
Sont-elles très différentes les unes des autres ?
Ou bien, elles diffèrent sur un seul critère ?

Cordialement.
Artemus24.
@+

[escartefigue]

Afin de rendre les traitements indépendants des données, on devrait toujours passer par des vues, ne jamais lire directement les tables dans les traitements.
Après leur nombre dépend du nombre de tables et du besoin.

[laurent1133]

Ok, alors les vues se ressemblent. J'ai voulu faire une base utilisateurs partagée entre plusieurs groupes. ( et J'ai une table avec le privilège Delete)...

[Artemus24]

Salut Laurent1133.

J'ai du mal à te suivre dans tes explications.

Ok, alors les vues se ressemblent.

Si elles sont presques identiques, mais différent sur un seul critère, il faut voir si l'on peut pas mettre ce critère en paramètre dans la view.

J'ai voulu faire une base utilisateurs partagée entre plusieurs groupes.

Il faut faire la distinction entre les privilèges d'accès aux tables que tu renseignes par un grant pour chaque utilisateur.
Et la façon d'accéder à cette table, enfin je devrais plutôt dire aux données.

Comme le dit Escartefigue, personne ne doit avoir accès aux tables diectement.
C'est une mauvaise façon de travailler car les accès doivent être gérés par les privilèges.
Et pour distinguer tel utilisateur qui est autorisé d'un autre qui ne l'est pas, cela doit se faire dans une View.

Prenons le cas où tu as deux utilisateurs.
L'un est autorisé à lire une colonne tandis que l'autre n'a pas l'autorisation.
Mais inversement, ils sont tous les deux autorisés à lire les autres colonnes.
Dans ce cas, tu dois créer deux View où dans l'une tu mets la colonne, et dans l'autre View, elle n'y figure pas.
Au niveau application, tu devras identifier l'utilisateur et fournir la bonne View.

Que ce passe-t-il si tu ne fais pas cette distinction ?
L'utilisateur qui n'est pas autorisé à lire la colonne en question, ne pourra pas lire les autres colonnes car sa requête va se terminer en erreur.

C'est très bien, quand il s'agit d'accès aux tables et aux colonnes.
Mais quand est-il si l'accès se fait sur certaines lignes mais pas sur d'autres ?
Dans ce cas, il faut étiqueter les lignes par une autre colonne qui va donner l'autorisation où pas.

Nommons cette colonne "critere".
Tu vas devoir gérer une table qui va contenir :
--> la fameuse colonne "critere"
--> l'identifiant de l'utilisateur
--> éventuellement le nom de la table où celui-ci désire accéder

et en résultat, tu sauras s'il est autorisé à l'accès ou pas.
C'est dans une View particulière que tu vas faire cette recherche d'autorisation.
Cette View, tu pourras l'appeler partout dans toutes tes autres Views quand tu as besoin de savoir qui est autorisé ou pas à accéder aux lignes.
En appliquant ce principe, tu risques d'avoir deux Views au maximum par table, mais pas plus.

Cordialement.
Artemus24.
@+

[laurent1133]

Merci pour ta réponse Artemus24, je vais essayé de l'appliqué. (Voici mon schéma actuel), tant que l'on utilise l'application rien de grave, en mode console pff !