Discussion :

[cestymour]

Bonjour,

J'ai une base de données avec une table STOCK et une table ARTICLE (un stock contient des articles évidemment).
Admettons que l'on puisse être soit un administrateur soit un utilisateur :
- L'utilisateur ne doit pouvoir supprimer un stock que s'il ne contient plus d'articles (<=> clause ON DELETE NO ACTION sur la table table stock).
- L'admin doit pouvoir supprimer un stock même s'il contient encore des articles (<=> clause ON DELETE CASCADE sur la table stock).

Y a-t-il un moyen de changer la clause dynamiquement ? Je ne pense pas qu'exécuter un ALTER TABLE ON DELETE ... à chaque fois qu'un admin ou un utilisateur veulent supprimer un stock soit une bonne idée, car on touche à la structure de la BDD alors qu'on est censé seulement l'utiliser, je trouve cela un peu dangereux.
Y a-t-il un autre moyen ? Est-ce qu'il faut vérifier manuellement que le stock ne contient plus d'article (sachant qu'en pratique j'ai beaucoup plus de tables reliées à STOCK) ?
Est-ce qu'il existe d'autres manières en SQL d'obtenir ce résultat ?

[aieeeuuuuu]

Bonjour,

Modifier la structure de la BDD n'est effectivement pas une bonne idée.

Vous pouvez passer par une procédure stockée qui intégrera la gestion des droits.

Comment savez vous si un utilisateur est admin ou pas ?
Comment gérez vous les droits ?

[cestymour]

Okay donc écrire une procédure stockée avec en gros si c'est un admin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ALTER TABLE ... ON DELETE CASACADE
...//Suppression du stock
ALTER TABLE ... ON DELETE NO ACTION //on revient à l'état initial

Quelque chose comme ça donc on resterait sur une modif temporaire de la bdd?

Les utilisateurs et admin sont stockés dans la table user qui contient un booléen isAdmin. La table user est reliée à une table qui contient les droits. Il y a aussi une table group reliée aux droits et a user pour gérer les droits par groupes d'utilisateurs. C'est un peu compliqué, c'est le framework qui gère ça bien mais je ne vois pas en quoi c'est important de savoir tout ça.

[aieeeuuuuu]

Non, je voyais plus simplement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
--si c'est un admin :
DELETE FROM ...
 
--sinon
--> Rien, ou erreur, ou...

[cestymour]

Okay merci, je vais peut-être faire comme ça, mais en réalité je n'ai pas que la table Article qui contient une foreign key vers Stock, j'ai 18 autres tables reliées aussi à Stock. Donc ça complique la procédure et le jour où j'ajoute une table à ma bdd il faudra que je modifie ma procédure stockée...

[aieeeuuuuu]

On s'est mal compris.

Rien ne vous empêche de mettre les suppressions en cascade.
Vous interdisez le delete sur la table à votre utilisateur SQL utilisé par votre application. Voire à tous les utilisateurs SQL non admin.

Et vous faites la procédure qui fait le DELETE uniquement sur la table Stock (avec suppression en cascade dans les 18 autres tables... attention quand même )

Ainsi, à part pour les admin SQL, la seule possibilité de supprimer des lignes dans votre table Stock est de passer par la procédure, qui effectuera les vérifications de droit nécessaires.

Si je vous demandais le mode de gestion des droits, c'était en effet pour éviter la confusion droit applicatif/privilège SQL.
Je suppose que votre application utilise le même login, que ce soit un utilisateur lambda, ou un administrateur (de l'application) qui se connecte ?

[cestymour]

Je suppose que votre application utilise le même login, que ce soit un utilisateur lambda, ou un administrateur (de l'application) qui se connecte ?

Exact, donc un admin au niveau de l'application n'a pas les privilèges de l'admin au sens SQL.

Vous interdisez le delete sur la table à votre utilisateur SQL utilisé par votre application. Voire à tous les utilisateurs SQL non admin.

Si j'ai bien compris, je l'interdis au niveau de l'application php et non de la base de données (je ne sais d'ailleurs pas si c'est possible d'interdire certaines requetes a un utilisateur SQL)

[aieeeuuuuu]

Non, vous l'interdisez au niveau de la base de données, afin que l'utilisateur SQL utilisé par votre application ne puisse pas faire de DELETE directement dans la table : il devra obligatoirement passer par la procédure stockée qui, elle, prendra en charge comme il se doit la gestion des droits.