Vos données d'audit doivent être stockées par table, plutôt que toutes au même endroit. Ce que vous feriez est de créer une table d'audit pour chacune des tables que vous souhaitez suivre et de créer des déclencheurs pour créer un enregistrement dans la table d'audit pour toute opération de manipulation de données sur la table auditée.
Il est certainement conseillé de désactiver DELETE opérations sur les items et item_options tables - ajouter des drapeaux comme item_active et item_option_active afin que vous puissiez les supprimer à la place. Il s'agit d'une pratique normale dans les situations où vous faites des choses comme stocker des factures qui font référence à des produits commandés dans le passé et avez besoin des données à des fins de rapport historique, mais pas pour une utilisation quotidienne.
Vos tables d'audit ne sont pas quelque chose que vous devez utiliser pour référencer d'anciennes données, votre modèle de données normal doit simplement prendre en charge le "masquage" des anciennes données là où il est probable qu'elles seront encore utilisées, et le stockage de plusieurs versions de données qui changeront avec le temps.
Pour l'audit, il est également utile de stocker le nom d'utilisateur du dernier utilisateur à modifier un enregistrement donné - lorsqu'il est utilisé à partir d'une application Web, vous ne pouvez pas utiliser le USER() de MySQL fonction pour obtenir des informations utiles sur qui est connecté. Ajouter une colonne et la remplir signifie que vous pouvez utiliser ces informations dans vos déclencheurs d'audit.
NB : Je suppose que vous n'autoriserez pas la modification des identifiants d'éléments dans des conditions normales - cela rendrait votre système d'audit plus complexe.
Si vous ajoutez des indicateurs actifs et des données de dernière modification à vos tables, elles ressembleront à :
Tableau des articles :
mysql> desc items;
+------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------------+--------------+------+-----+---------+----------------+
| item_id | int(11) | NO | PRI | NULL | auto_increment |
| item_name | varchar(100) | YES | | NULL | |
| item_description | text | YES | | NULL | |
| item_active | tinyint(4) | YES | | NULL | |
| modified_by | varchar(50) | YES | | NULL | |
+------------------+--------------+------+-----+---------+----------------+
Tableau des options d'articles :
mysql> desc item_options;
+---------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+--------------+------+-----+---------+----------------+
| option_id | int(11) | NO | PRI | NULL | auto_increment |
| item_id | int(11) | YES | MUL | NULL | |
| option_name | varchar(100) | YES | | NULL | |
| option_price | int(11) | YES | | NULL | |
| option_active | tinyint(4) | YES | | NULL | |
| modified_by | varchar(50) | YES | | NULL | |
+---------------+--------------+------+-----+---------+----------------+
Vos tables d'audit doivent stocker quatre informations supplémentaires :
- ID d'audit :cet ID n'est unique que pour l'historique de ceci table, ce n'est pas une valeur globale
- Modification effectuée par - l'utilisateur de la base de données qui a effectué la modification
- Modifier la date/l'heure
- Type d'action -
INSERTouUPDATE(ouDELETEsi vous l'autorisiez)
Vos tableaux d'audit devraient ressembler à :
Tableau d'audit des articles :
mysql> desc items_audit;
+------------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------------+--------------+------+-----+---------+----------------+
| audit_id | int(11) | NO | PRI | NULL | auto_increment |
| item_id | int(11) | YES | | NULL | |
| item_name | varchar(100) | YES | | NULL | |
| item_description | text | YES | | NULL | |
| item_active | tinyint(4) | YES | | NULL | |
| modified_by | varchar(50) | YES | | NULL | |
| change_by | varchar(50) | YES | | NULL | |
| change_date | datetime | YES | | NULL | |
| action | varchar(10) | YES | | NULL | |
+------------------+--------------+------+-----+---------+----------------+
Tableau d'audit des options d'articles :
mysql> desc item_options_audit;
+---------------+--------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------+--------------+------+-----+---------+----------------+
| audit_id | int(11) | NO | PRI | NULL | auto_increment |
| option_id | int(11) | YES | | NULL | |
| item_id | int(11) | YES | | NULL | |
| option_name | varchar(100) | YES | | NULL | |
| option_price | int(11) | YES | | NULL | |
| option_active | tinyint(4) | YES | | NULL | |
| modified_by | varchar(50) | YES | | NULL | |
| change_by | varchar(50) | YES | | NULL | |
| change_date | datetime | YES | | NULL | |
| action | varchar(10) | YES | | NULL | |
+---------------+--------------+------+-----+---------+----------------+
N'utilisez pas de clés étrangères sur vos tables d'audit ; les lignes des tables d'audit ne sont pas des lignes enfants des enregistrements qu'elles auditent, les clés étrangères ne sont donc d'aucune utilité.
Déclencheurs
NB : MySQL ne prend pas en charge les déclencheurs de type multi-instructions, vous en avez donc besoin d'un pour chacun des INSERT , UPDATE et DELETE (le cas échéant).
Vos déclencheurs doivent simplement INSERT tous les NEW valeurs dans la table d'audit. Les définitions de déclencheur pour les items le tableau peut être :
/* Trigger for INSERT statements on the items table */
CREATE DEFINER=`root`@`localhost` TRIGGER trigger_items_insert_audit
AFTER INSERT ON items
FOR EACH ROW BEGIN
INSERT INTO items_audit (
item_id, item_name, item_description,
item_active, modified_by, change_by,
change_date, action
) VALUES (
NEW.item_id, NEW.item_name, NEW.item_description,
NEW.item_active, NEW.modified_by, USER(),
NOW(), 'INSERT'
);
END;
/* Trigger for UPDATE statements on the items table */
CREATE DEFINER=`root`@`localhost` TRIGGER trigger_items_update_audit
AFTER UPDATE ON items
FOR EACH ROW BEGIN
INSERT INTO items_audit (
item_id, item_name, item_description,
item_active, modified_by, change_by,
change_date, action
) VALUES (
NEW.item_id, NEW.item_name, NEW.item_description,
NEW.item_active, NEW.modified_by, USER(),
NOW(), 'UPDATE'
);
END;
Créez des déclencheurs similaires pour les item_options tableau.
Mise à jour :Historique des données dans le commerce électronique
L'audit que nous avons effectué ci-dessus vous permettra de conserver un historique de n'importe quelle table de base de données, mais crée un magasin de données qui ne convient pas aux données auxquelles il faut accéder régulièrement.
Dans un système de commerce électronique, garder utilisable les données historiques sont importantes, afin que vous puissiez modifier les attributs tout en présentant les anciennes valeurs dans certaines situations.
Cela doit être complètement séparé de votre solution d'audit
La meilleure façon de stocker l'historique est de créer une table d'historique pour chaque attribut qui doit être stocké historiquement. Cette question Stackoverflow contient de bonnes informations sur la conservation d'un historique d'un attribut donné .
Dans votre situation, si vous n'êtes préoccupé que par le prix et le titre, vous devez créer un prices table, et un item_titles table. Chacun aurait une clé étrangère vers les item_options table ou les items table (les tables maîtres stockeraient toujours le courant prix ou titre), et aurait le prix ou le titre, avec ses dates d'entrée en vigueur. Ces tables doivent avoir des autorisations précises (éventuellement basées sur des colonnes) pour éviter de mettre à jour le effective_from dates et les valeurs réelles une fois l'enregistrement inséré.
Vous devez également utiliser la solution d'audit ci-dessus sur ces tableaux.
