14

多くのソリューションで見られる各レコードの2つの追加列（timeCreated、timeLastUpdated）について質問があります。私の質問：より良い代替案はありますか？

シナリオ：（レコードではなくテーブルに関して）巨大なDBがあり、顧客が来て、テーブルの80％に「タイムスタンピング」を追加するように求めてきます。

これは、別のテーブル（TIMESTAMPS）を使用することで実現できると思います。このテーブルには、明らかなタイムスタンプ列に加えて、更新されるテーブルのテーブル名と主キーが含まれます。（ここでは、ほとんどのテーブルの主キーとしてintを使用していると想定していますが、テーブル名は文字列である必要があります）。

これを描くために、この基本的なシナリオを想定します。2つのテーブルがあります。

支払い:-(通常のレコード）
タイムスタンプ：-{現在のタイムスタンプ} + { TABLE_UPDATED、、}id_of_entry_updatedtimestamp_type

この設計では、とによってインデックスを作成しているため、ネイティブの支払いオブジェクトにこれらの2つの「余分な」列は必要ありません（ちなみに、ORMソリューションを通過する可能性がありますTABLE_UPDATED）id_of_entry_updated。さらにtimestamp_type、エントリが挿入用（「1」など）、更新用（「2」など）、および「削除」などの追加したいものがあるかどうかを通知します。

このデザインについてどう思いますか？私はベストプラクティス、何が機能し、時間の経過とともに拡大するかに最も興味があります。参照、リンク、ブログエントリは大歓迎です。この問題に対処しようとしている特許（係属中）を少なくとも1つ知っていますが、現時点では詳細は公開されていないようです。

乾杯、エドゥアルド

4

11 に答える 11

12

その間、変更を加えたユーザーも記録します。

（他の人が強調した結合パフォーマンスに加えて）個別のテーブル設計の欠点は、すべてのテーブルにキーのID列があることを前提としていることです。それは必ずしも真実ではありません。

SQL Serverを使用している場合、新しい2008バージョンは、彼らが呼んChange Data Captureでいるものをサポートしており、あなたが話している多くの苦痛を取り除くはずです。オラクルにも似たようなものがあると思います。

更新：どうやらOracleはそれをSQLServerと同じものと呼んでいます。むしろ、Oracleの実装が最初に来たので、SQL ServerはそれをOracleと同じものと呼んでいます;）
http://www.oracle.com/technology/oramag/oracle/03-nov/o63tech_bi.html

于 2008-09-30T20:41:50.523 に答える
10

監査対象の各テーブルに2つのテーブルがある設計を使用しました。

create table NAME (
  name_id int,
  first_name varchar
  last_name varchar
  -- any other table/column constraints
)

create table NAME_AUDIT (
  name_audit_id int
  name_id int
  first_name varchar
  last_name varchar
  update_type char(1) -- 'U', 'D', 'C'
  update_date datetime
  -- no table constraints really, outside of name_audit_id as PK
)

NAME_AUDITに何かが行われるたびに設定されるデータベーストリガーが作成されNAMEます。このようにして、テーブルに加えられたすべての変更とその時期の記録があります。アプリケーションはデータベーストリガーによって維持されるため、これについての実際の知識はありません。

それはかなりうまく機能し、実装するためにアプリケーションコードに変更を加える必要はありません。

于 2008-09-30T20:45:02.450 に答える
5

個々のテーブルにタイムスタンプを追加する方が好きだと思います。複合キー（そのうちの1つは文字列）でタイムスタンプテーブルに結合するのは遅くなり、大量のデータがある場合、最終的には実際の問題になります。

また、タイムスタンプを確認するときは、アプリケーションの問題をデバッグしているときに、常に他のテーブルと結合するのではなく、その場でデータが必要になることがよくあります。

于 2008-09-30T20:41:39.087 に答える
2

設計の悪夢の 1 つは、すべての挿入、更新、または削除がそのテーブルにヒットしなければならないことです。これにより、パフォーマンスとロックに関する重大な問題が発生する可能性があります。そのようなテーブルを一般化するのは悪い考えです (タイムスタンプだけでなく)。データを取り出すのも悪夢です。

ユーザーに見せたくないフィールドを追加して GUI レベルでコードが壊れる場合は、必要な最小数の列のみを指定し、* を選択しないようにするコードを GUI に誤って記述しています。

于 2009-01-27T22:32:50.687 に答える
1

提案する方法の利点は、変更を加えたユーザーを追跡するなど、TIMESTAMPテーブルに他のフィールドを追加するオプションが提供されることです。機密フィールドへの編集を追跡することもできます。たとえば、誰がこの契約の価格を変更しましたか？

レコードの変更を別のファイルに記録すると、次のようにレコードに複数の変更を表示できます。

mm / dd / yy hh：mm：ssXXXによって追加mm/ dd / yy hh：mm：ssフィールド価格XXXによって変更、mm / dd / yy hh：mm：ssXXXによってレコードが削除されました

欠点の1つは、メインテーブルの変更を反映するためにTIMESTAMPSテーブルへの挿入を実行する余分なコードです。

于 2008-09-30T20:40:29.420 に答える
1

トリガーを実行するようにタイムスタンプを設定すると、トリガーを開始できるアクション（読み取り？）をログに記録できます。また、いくつかのロックの利点があるかもしれません。

（私はDBAでもSQLの第一人者でもありません）

于 2008-09-30T20:43:28.677 に答える
1

はい、私はそのデザインが好きで、いくつかのシステムでそれを使用しています。通常、次のいくつかのバリアント：

LogID  int
Action varchar(1)     -- ADDED (A)/UPDATED (U)/DELETED (D)
UserID varchar(20)    -- UserID of culprit :)
Timestamp datetime    -- Date/Time
TableName varchar(50) -- Table Name or Stored Procedure ran
UniqueID int          -- Unique ID of record acted upon
Notes varchar(1000)   -- Other notes Stored Procedure or Application may provide
于 2008-09-30T20:45:13.073 に答える
0

タイムスタンプを取得するために実行する必要のある追加の結合は、わずかなパフォーマンスヒットと首の痛みになると思います。それ以外は問題ありません。

于 2008-09-30T20:41:45.843 に答える
0

私たちはあなたがしたことを正確に行いました。これは、オブジェクトモデルと、最小限のコードで新しいスタンプやさまざまな種類のスタンプをモデルに追加する機能に最適です。また、変更を加えたユーザーを追跡しており、ロジックの多くはこれらのスタンプに大きく基づいていました。とてもよく目が覚めました。

欠点の1つは、レポートを作成したり、画面にさまざまなスタンプを表示したりすることです。私たちが行った方法でそれを行っている場合、それは多くの結合を引き起こしました。また、バックエンドの変更は苦痛でした。

于 2008-09-30T20:48:29.197 に答える
0

私たちの解決策は、「セッション」テーブルに加えて「トランザクション」テーブルを維持することです。UPDATE、INSERT、および DELETE 命令はすべて「Transaction」オブジェクトを介して管理され、これらの SQL 命令はそれぞれ、データベースで正常に実行されると「Transaction」テーブルに格納されます。この「Transaction」テーブルには、transactiontType (INSERT の場合は I、DELETE の場合は D、UPDATE の場合は U)、transactionDateTime などの他のフィールドと、最終的に誰が命令を送信したかを示す外部キー「sessionId」があります。一部のコードを使用して、誰がいつ何をしたかを特定することもできます (Gus は月曜日にレコードを作成し、Tim は火曜日に単価を変更し、Liz は木曜日に特別割引を追加したなど)。

このソリューションの長所は次のとおりです。

  1. 「誰が、いつ」を伝え、それをユーザーに見せることができます! (SQL ステートメントを分析するためのコードが必要になります)
  2. データが複製され、複製が失敗した場合は、このテーブルを使用してデータベースを再構築できます

短所は

  1. 1 か月あたり 100,000 のデータ更新は、Tbl_Transaction の 100,000 レコードを意味します
  2. 最後に、このテーブルはデータベース ボリュームの 99% になる傾向があります。

私たちの選択: 90 日以上経過したすべての記録は毎朝自動的に削除されます

于 2008-10-02T20:42:28.587 に答える
-1

フィリップ、

90日以上経過したものを単に削除したり、最初に別のDBに移動したり、テキストファイルに書き込んだりして、保存するために何かをして、メインの本番DBから移動するだけではいけません。

突き詰めると、ほとんどの場合、「ドキュメントが多い方が勝つ」というケースです。

于 2008-12-09T18:44:30.917 に答える