Nous avons quelque chose de similaire sur l'un de nos sites, nous avons ajouté un tas de tableaux :
users sites ...etc
Ensuite, nous avons un tas de tables fantômes :
users-shadow sites-shadow ...etc
Les tables fantômes ont des structures identiques aux tables réelles à l'exception d'une ligne ajoutée pour l'utilisateur qui a effectué la modification. Nous utilisons donc d'abord cette requête lorsqu'une modification est soumise par un utilisateur qui doit faire approuver ses actions de base de données :
REPLACE INTO users-shadow (user_mod,id,username,password,salt...) VALUES (16,50,'bob','stuff','salt'...);
Évidemment, assurez-vous que ce n'est pas ouvert à l'injection, utilisez déclarations préparées etc.
Une fois approuvé, une ligne dans le shadow la table est simplement supprimée du shadow table, le user_mod valeur supprimée et modifications (valeurs non nulles) insérées dans la table réelle (ou mise à jour si un id est spécifié, en utilisant REPLACE
syntaxe). Nous faisons cette logique en perl, donc malheureusement, nous n'avons pas de SQL sous la main pour cela.
N'oubliez pas que SQL REPLACE fait un DELETE et un INSERT plutôt qu'une UPDATE . Vous devrez modifier tous les déclencheurs pour permettre ce comportement.
Remarque :La raison pour laquelle nous n'avons pas utilisé d'indicateur "approuver" était que nous avions besoin de la possibilité de modifier les enregistrements existants, bien sûr, nous ne pouvions pas avoir plusieurs enregistrements avec la même clé primaire.
