Ihre Audit-Daten sollten pro Tabelle und nicht an einem Ort gespeichert werden. Was Sie tun würden, wäre, eine Audit-Tabelle für jede der Tabellen zu erstellen, die Sie nachverfolgen möchten, und Trigger zu erstellen, um einen Datensatz in der Audit-Tabelle für jeden Datenmanipulationsvorgang in der überwachten Tabelle zu erstellen.
Es ist auf jeden Fall ratsam, DELETE zu verbieten Operationen auf den items und item_options Tabellen - fügen Sie Flags wie item_active hinzu und item_option_active damit Sie sie stattdessen vorläufig löschen können. Dies ist gängige Praxis in Situationen, in denen Sie beispielsweise Rechnungen speichern, die sich auf in der Vergangenheit bestellte Produkte beziehen, und die Daten für historische Berichtszwecke benötigen, jedoch nicht für den täglichen Gebrauch.
Ihre Audit-Tabellen sollten Sie nicht zum Referenzieren alter Daten verwenden, Ihr normales Datenmodell sollte das einfache „Verbergen“ alter Daten dort unterstützen, wo sie wahrscheinlich noch verwendet werden, und das Speichern mehrerer Versionen von Daten, die sich im Laufe der Zeit ändern werden.
Für die Überwachung ist es auch nützlich, den Benutzernamen des letzten Benutzers zu speichern, der einen bestimmten Datensatz geändert hat – wenn er von einer Webanwendung verwendet wird, können Sie MySQLs USER() nicht verwenden Funktion, um nützliche Informationen darüber zu erhalten, wer angemeldet ist. Wenn Sie eine Spalte hinzufügen und füllen, können Sie diese Informationen in Ihren Audit-Triggern verwenden.
Hinweis: Ich gehe davon aus, dass Sie unter normalen Bedingungen nicht zulassen, dass Artikel-IDs geändert werden - das würde Ihr Überwachungssystem komplexer machen.
Wenn Sie Ihren Tabellen Aktiv-Flags und Zuletzt-geändert-von-Daten hinzufügen, sehen sie etwa so aus:
Artikeltabelle:
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 | |
+------------------+--------------+------+-----+---------+----------------+
Artikeloptionentabelle:
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 | |
+---------------+--------------+------+-----+---------+----------------+
Ihre Audit-Tabellen müssen vier zusätzliche Informationen speichern:
- Audit-ID - diese ID ist nur für den Verlauf eindeutig Tabelle, es ist kein globaler Wert
- Änderung vorgenommen von – der Datenbankbenutzer, der die Änderung vorgenommen hat
- Datum/Uhrzeit ändern
- Aktionstyp -
INSERToderUPDATE(oderDELETEwenn Sie es zulassen würden)
Ihre Audit-Tabellen sollten in etwa so aussehen:
Überwachungstabelle für Elemente:
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 | |
+------------------+--------------+------+-----+---------+----------------+
Überwachungstabelle für Artikeloptionen:
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 | |
+---------------+--------------+------+-----+---------+----------------+
Verwenden Sie keine Fremdschlüssel in Ihren Audit-Tabellen; die Zeilen in den Audit-Tabellen sind keine untergeordneten Zeilen der Datensätze, die sie auditieren, daher sind Fremdschlüssel nutzlos.
Auslöser
Hinweis: MySQL unterstützt keine Multi-Statement-Trigger, also brauchen Sie einen für jeden von INSERT , UPDATE und DELETE (falls zutreffend).
Ihre Trigger müssen einfach INSERT werden alles NEW Werte in die Audit-Tabelle. Die Triggerdefinitionen für die items Tabelle könnte sein:
/* 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;
Erstellen Sie ähnliche Trigger für die item_options Tabelle.
Update:Datenhistorie im E-Commerce
Die oben durchgeführte Prüfung ermöglicht es Ihnen, einen Verlauf einer beliebigen Datenbanktabelle zu führen, erstellt jedoch einen Datenspeicher, der nicht für die Verwendung von Daten geeignet ist, auf die regelmäßig zugegriffen werden muss.
In einem E-Commerce-System brauchbar bleiben historische Daten sind wichtig, damit Sie in bestimmten Situationen Attribute ändern und alte Werte anzeigen können.
Dies sollte vollständig von Ihrer Auditing-Lösung getrennt sein
Der beste Weg, den Verlauf zu speichern, besteht darin, eine Verlaufstabelle für jedes Attribut zu erstellen das muss historisch gespeichert werden. Diese Stackoverflow-Frage enthält einige gute Informationen zum Aufbewahren eines Verlaufs eines bestimmten Attributs .
Wenn Sie in Ihrer Situation nur an Preis und Titel interessiert sind, würden Sie einen prices erstellen Tabelle und ein item_titles Tisch. Jeder hätte einen Fremdschlüssel zu den item_options Tabelle oder die items Tabelle (die Haupttabellen würden immer noch die aktuelle speichern Preis oder Titel) und würde den Preis oder Titel mit seinen Gültigkeitsdaten enthalten. Diese Tabellen sollten differenzierte (möglicherweise spaltenbasierte) Berechtigungen haben, um eine Aktualisierung von effective_from zu vermeiden Datumsangaben und die tatsächlichen Werte nach dem Einfügen des Datensatzes.
Sie sollten die obige Auditing-Lösung auch für diese Tabellen verwenden.
