監査データは、すべてを1か所に保存するのではなく、テーブルごとに保存する必要があります。追跡するテーブルごとに監査テーブルを作成し、監査テーブルでのデータ操作操作のために監査テーブルにレコードを作成するトリガーを作成します。
DELETEを禁止することを強くお勧めします itemsの操作 およびitem_options テーブル-item_activeのようなフラグを追加します およびitem_option_active 代わりにそれらをsoftdeleteできるようにします。これは、過去に注文した製品を参照する請求書を保存するなどの状況での通常の慣行であり、履歴レポートの目的でデータを必要としますが、日常の使用には必要ありません。
監査テーブルは、古いデータを参照するために使用する必要があるものではありません。通常のデータモデルは、古いデータが引き続き使用される可能性が高い場所で単に「非表示」にし、時間の経過とともに変化するデータの複数のバージョンを保存することをサポートする必要があります。
監査の場合、特定のレコードを変更する最後のユーザーのユーザー名を保存することも役立ちます。Webアプリケーションから使用する場合、MySQLのUSER()を使用することはできません。 誰がログオンしているかに関する有用な情報を取得する関数。列を追加してデータを入力するということは、その情報を監査トリガーで使用できることを意味します。
NB： 通常の状態ではアイテムIDを変更できないと想定します。これにより、監査システムがより複雑になります。
アクティブなフラグと最終変更者データをテーブルに追加すると、次のようになります。
アイテムテーブル：
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 | |
+------------------+--------------+------+-----+---------+----------------+
アイテムオプションテーブル：
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 | |
+---------------+--------------+------+-----+---------+----------------+
監査テーブルには、4つの追加情報を保存する必要があります。
- 監査ID-このIDは、これの履歴に対してのみ一意です。 テーブル、それはグローバルな値ではありません
- 変更者-変更を行ったデータベースユーザー
- 日付/時刻の変更
- アクションタイプ-
INSERTまたはUPDATE（またはDELETE許可している場合）
監査テーブルは次のようになります。
アイテム監査テーブル：
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 | |
+------------------+--------------+------+-----+---------+----------------+
アイテムオプション監査テーブル：
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 | |
+---------------+--------------+------+-----+---------+----------------+
監査テーブルで外部キーを使用しないでください。監査テーブルの行は、監査しているレコードの子行ではないため、外部キーは役に立ちません。
トリガー
NB： MySQLはマルチステートメントタイプのトリガーをサポートしていないため、INSERTごとに1つ必要です。 、UPDATE およびDELETE （該当する場合）。
トリガーは単にINSERTする必要があります すべてのNEW 値を監査テーブルに追加します。 itemsのトリガー定義 テーブルは次のようになります：
/* 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;
item_optionsに対して同様のトリガーを作成します テーブル。
更新：Eコマースのデータ履歴
上記で行った監査では、特定のデータベーステーブルの履歴を保持できますが、定期的にアクセスする必要のあるデータの使用には適さないデータストアが作成されます。
eコマースシステムで、使用可能を維持する 特定の状況で古い値を表示しながら属性を変更できるように、履歴データは重要です。
これは、監査ソリューションとは完全に分離する必要があります
履歴を保存する最良の方法は、各属性の履歴テーブルを作成することです。 それは歴史的に保存する必要があります。 このStackoverflowの質問には、特定の属性の履歴を保持するためのいくつかの良い情報があります 。
あなたの状況では、価格とタイトルだけが気になる場合は、pricesを作成します テーブル、およびitem_titles テーブル。それぞれがitem_optionsのいずれかへの外部キーを持っています テーブルまたはitems テーブル（マスターテーブルには引き続き現在が保存されます 価格、またはタイトル）、およびその発効日とともに価格またはタイトルがあります。これらのテーブルには、effective_fromの更新を回避するために、きめ細かい（場合によっては列ベースの）権限が必要です。 日付、およびレコードが挿入された後の実際の値。
これらの表でも上記の監査ソリューションを使用する必要があります。