2

次のフィールドを持つusersテーブルがあります: userid, phone, and address. これはユーザーデータなので、ユーザーがいつでも変更できるようにしています。問題は、これらの変更を追跡し、古いデータも保持したいということです。私が検討したアイデアのいくつかを次に示します。

  • 新しいデータを古いデータに追加し、パイプのようなセパレーターを使用します。フィールドを取得するときに、そのセパレーターの存在を確認し、存在する場合は、その後の文字を新しいデータとして取得します。(面倒だし気持ち悪い)

  • changes次のフィールドを持つ別のテーブルを設定します: userid, fieldname, fieldcontent. ユーザーがデータ (任意のデータ) を変更した場合、ユーザーのユーザー ID、フィールドの名前/ID、およびフィールドの古いコンテンツの下にあるこの別のテーブルにイベントを記録し、古いデータを上書きできるようになりました。users新しいものと一緒に。このユーザーが行ったすべての変更を見つけたい場合は、ユーザーchangesID でテーブルを検索します。これに関する問題は、(すべてのフィールドの) すべてのデータ変更を 1 つのテーブルに混在させているため、さまざまなフィールド タイプに対応するためにfieldcontentフィールドをchangesテキストにする必要があることです。これはまだ最初のアイデアよりも優れているように見えますが、正しいことをしているかどうかはまだわかりません.

古いデータを保持するための他のアイデアや既知のベスト プラクティスはありますか?

前もって感謝します

4

3 に答える 3

3

あなたが何をするにしても、最初のものをしないでください。

変更テーブルはより良いアプローチです。これは、監査テーブルまたは履歴テーブルとも呼ばれます。ただし、キーと値のペアの履歴は作成しません。代わりに、関連するテーブルごとに履歴を作成します。これは、アプリケーション コードまたはデータベース トリガーを介して行うことができます。基本的に、挿入、更新、または削除が発生するたびに、何が発生し、どのデータが変更されたかを記録します。

テーブル ユーザー:

  • ID
  • ユーザー名
  • 電子メールアドレス
  • 電話
  • 住所

テーブル user_history:

  • ID
  • change_type (挿入、更新、または削除の場合は I、U、または D)
  • user_id (FK user.id)
  • 電子メールアドレス
  • 電話
  • 住所
  • 変更日時
  • オプションで、レコードを変更した人も保存します
于 2009-10-12T03:14:04.413 に答える
1

このような変更を追跡するために使用した非常に簡単な方法は次のとおりです。

users_history` 
    userid 
    changenumber smallint not null
    changedate datetime not null
    changeaddr varchar(32) not null
    phone NULL,
    address NULL

    primary key on (userid, linenumber)

テーブルのレコードを INSERT または UPDATE するusersたびに、users_history テーブルに新しいレコードを INSERT するだけです。 changenumber1 から始まり、そこから増加します。 changedateいつどこで追跡するためにchangeaddr使用できます。

users_historyフィールド値が変更されていない場合は、それぞれのテーブル フィールドに自由に NULL を入れてください。

結局のところ、アプリはテーブルにかさばる履歴データを変更したり保存したりする必要はありませんが、usersすべてを指先で行うことができます。

編集：

これにより、古いデータが保持されます。ユーザーが特定の住所と電話で開始し、4 日後に住所を更新し、5 日後に電話を更新した次の例を参照してください。 あなたはすべてを持っています。

現在のユーザー レコード:

100                            |  234-567-8901   |   123 Sesame Street


サンプル履歴テーブル

100   |  1  | 2009-10-01 12:00 |  123-456-7890   |   555 Johnson Street
100   |  2  | 2009-10-05 13:00 |  NULL           |   123 Sesame Street
100   |  3  | 2009-10-10 15:00 |  234-567-8901   |   NULL
于 2009-10-12T03:15:08.393 に答える
0

これを実装する最も簡単な方法は、履歴のためだけに別のテーブル、スナップショットを用意することです。すべてのフィールドをミラーリングする必要はありません。

change_id // row id (just for easy management later on if you need to delete specific row, otherwise its not really necessary)
user_id // Original user id
change_time // time of change
data // serialized data before change.
于 2009-10-12T04:37:02.550 に答える