3

データベース テーブルは、テキスト ドキュメントへの編集変更を保存するために使用されます。

idデータベース テーブルには、{ 、timestamp、user_id、text}の 4 つの列があります。

ユーザーがドキュメントを編集するたびに、新しい行がテーブルに追加されます。新しい行には、自動インクリメントされた ID と、データが保存された時刻に一致するタイムスタンプがあります。

特定の編集中にユーザーが行った編集変更を判別するために、ユーザーの編集に応じて挿入された行のが、以前に挿入された行のtextと比較されます。text

どの行が以前に挿入された行であるかを判断するには、id列または列のいずれかtimestampを使用できます。私が見る限り、どの方法にも長所と短所があります。

を使用して作成順序を決定するid

  • 利点: システム クロックの設定が不適切なために発生する問題の影響を受けません。

  • id短所:列に同一性以外の意味を規定するため、列の悪用のようidです。管理者は、ID のセットが一意である限り値が何であるかは問題にならないため、何らかの理由 (データ移行中など) で ID のセットの値を変更する可能性があります。その後、行の作成順序を判別できなくなりました。

を使用して作成順序を決定するtimestamp

  • 利点:id列は ID のみにtimestamp使用され、本来あるべきように時間に使用されます。
  • 欠点: この方法は、行がテーブルに挿入されるたびにシステム クロックが正しく設定されていることがわかっている場合にのみ信頼できます。システム クロックが挿入ごとに正しく設定されていることをどのように確信できますか? また、システム クロックが過去の正確には知られていない期間に誤って設定されていたことが判明した場合、テーブルの状態をどのように修正できますか?

ある方法を他の方法よりも優先して選択するための強力な議論、または私が検討している 2 つの方法よりも優れた別の方法の説明を求めています。

4

3 に答える 3

1

または、編集順序を記録することのみを目的とする別の列を追加します。これにはdatetimeを使用しないことをお勧めします。

于 2012-11-21T03:49:37.177 に答える
1

ID を使用します。シンプルで機能します。

唯一の注意点は、ストア アンド フォワード サーバーから定期的に行を追加する場合です。その場合、行は後で追加される可能性がありますが、以前に追加されたものとして扱う必要があります。

于 2012-11-21T03:43:01.713 に答える
1

シーケンシャルidを使用すると、おそらく（？）主キーであり、インデックスが付けられてアクセスが速くなるため、より簡単になります。があるとすればuser_id、最後の編集と以前の編集をすばやく確認できます。

を使用するtimestampこともできますが、エントリが長くなる可能性が高く、インデックスが作成されているかどうかはわかりません。また、衝突の可能性もあります。システムクロックは変更できることを正しく指摘しています...一方、シーケンシャルは変更idできません。

あなたの更新を考えると：

正確な要件を確認するのは難しいため、特定のプロジェクトで 20 万件以上の複雑なドキュメントと数百万回の改訂が必要であったことの証拠としてこれを含めました。

私自身の経験 (完全に監査可能なドキュメント/プロファイリング システムの構築) から、60 人を超えるフルタイムの研究者からなる社内チームのために。最終的に、監査証跡と完全なバージョン管理を提供するために、idおよび他の多くのフィールド ( を含む) の両方を使用することになりました。timestamp

私たちが構築したシステムには、プロファイルごとに 200 を超えるフィールドがあるため、ドキュメントのバージョン管理は、それぞれの変更されたテキスト/コンテンツのブロックを保存するよりもはるかに複雑でした。それでも、各プロファイルは、編集、承認、却下、ロールバック、公開、さらには PDF またはその他の形式で 1 ​​つのドキュメントとしてエクスポートできます。

(多くの戦略/計画の後に) 最終的に行ったことは、プロファイルの連続したバージョンを保存することでしたが、それらは主にフィールドにid基づいていました。

タイムスタンプ

タイムスタンプも二次チェックとして取得され、タイムアライメントを定期的にチェックし、必要に応じて修正する cron スクリプトを使用して、(サーバーのクラスター間で) システムクロックを正確に保つようにしました。また、 Ntpdを使用してクロック ドリフトを防止しました。

その他の撮影データ

各編集でキャプチャされたその他のデータも含まれます (ただし、これらに限定されません)。

User_id
User_group
Action
Approval_id

内部要件 (ドキュメントの自動生成された注釈を含む) を満たす他のテーブルもありました。プロファイルの編集の一部はボット (NER/機械学習/AI を使用して構築) のデータを使用して行われましたが、いずれかの承認が必要でした。編集/更新が公開される前のチーム。

すべてのユーザー アクションのアクション ログも保持されていたため、監査の際に個々のユーザーのアクションを確認できました。ユーザーがそのようなアクションを実行する権限を持っていなくても、ログに記録されていました。 .

移行に関しては、データの移動/ダンプ/転送で ID シーケンスを簡単に保持できるため、大きな問題とは思いません。おそらく唯一の問題は、データセットをマージする必要がある場合です。その場合はいつでも移行スクリプトを作成できます。そのため、個人的な観点からは、その欠点が多少減少したと考えています。

そこにあるデータエクスプローラーのスタックオーバーフローテーブル構造を見る価値があるかもしれません（これはかなり洗練されています）。ここでテーブル構造を確認できます: https://data.stackexchange.com/stackoverflow/query/new、これはメタに関する質問から来ています: SO はリビジョンをどのように保存しますか?

リビジョン システムとして SO はうまく機能し、マークダウン/リビジョン機能はおそらく良い例です。

于 2012-11-21T03:46:46.870 に答える