1

テーブル A を含むプライマリ データベースと、A の別のコピーを含むセカンダリ データベースがあります。アプリケーションを起動するたびに、プライマリ データベースのテーブル A のすべての行がチェックされ、セカンダリ データベースの A の行が更新されます。

この醜い動作の必要性は、レガシー データベースのサポートですが、起動のたびにこの操作を行うと、非常に CPU コストがかかり始めます。行が更新されたときに、タイムスタンプ (Microsoft では行バージョンとも呼ばれます) を保存できることがわかりました。

したがって、私のアプリケーションは、最後に変更/挿入された行の最後のタイムスタンプを保存する必要があり、その後の再起動では、データベースから変更された行 (または挿入された新しい行) についてプライマリ データベースにクエリを実行するだけです。

これにより、処理が大幅に高速化されますが、削除された行をどのように処理すればよいでしょうか?? ありがとうございました

編集:読み取り専用モードでプライマリデータベースにのみアクセスすることに気付きました。したがって、元のデータベースにタイムスタンプを入れることはできません。また、何らかの方法でトリガーを挿入することもできません。

プライマリ データベースを変更せずに変更内容をすばやく確認できる方法はありますか?

4

3 に答える 3

1

構築している機能は、多くのデータベースエンジンによって「そのまま」サポートされています。これはレプリケーションと呼ばれます。

H2の場合、これはすぐに使用できる機能ではありませんが、SymetricDSと呼ばれる機能としてこれを提供しているように見えるオープンソースツールがあります。FAQによると、H2で動作します。

独自のレプリケーションスキームではなく、これを使用することを検討します。多くの時間を費やさない限り、自分で作成するものよりも高速で堅牢になる可能性があります。

于 2013-03-15T16:11:28.390 に答える
0

スレーブ側で処理するために、削除された行にフラグを付ける何らかの方法が必要です。これは、行が削除されたときに、行全体または (table, id) タプルだけを別のテーブルに保存するトリガーを使用するのに適したケースです。これを新しいdeleted_rowsテーブルと呼びます。

次に、アプリが起動するとdeleted_rows、トリガーによって設定されたテーブルが読み取られ、それらの変更がスレーブ データベースに適用されます。deleted_rows後でそれらのレコードを再処理しようとする手間がかからないように、完了したら必ずクリアしてください。

于 2013-03-15T13:30:49.480 に答える
0

(1) テーブル A に主キーがあると仮定し、テーブル B の主キーのみを記録するテーブルを作成します。アプリケーションの起動時に、A に存在しなくなった B の行をチェックして、削除された行を取得します。(その逆は、新しい/挿入された行を取得します。)

（2）行バージョン（上記と組み合わせて）は、まさにあなたが望むものに理想的です。そうしないと、チェックサムの一部が使用される可能性があります。関数としての MS SQL Server CHECKSUM()。データ行全体の内容に基づいてハッシュ値を生成するために使用できます。(ハッシュ値が一意であることを保証することはできませんが、ハッシュ値と主キー値の両方をチェックするため、特にここではハッシュ値で十分です。主キーはハッシュ計算で使用されます。) アプリケーションの起動時に、テーブル A の既存のすべての行のハッシュ値を計算し、上記で作成した追跡テーブルと照合します。

  • 新しいセットの主キーが B に見つからない場合、それは新しい行であり、主キーとハッシュ値を挿入します
  • B の主キーが新しいセットに見つからない場合、それは削除された行です。削除します
  • B と新しいセットで見つかった主キーとハッシュ値が異なる場合、行が更新されているため、それに応じて処理します
  • B と新しいセットで見つかった主キーとハッシュ値が一致する場合、行は更新されていません

悲しいことに、テーブル A にはまだ完全なテーブル スキャンが必要なため、上記の実装ではそれほど時間の節約にはならないのではないかと思います。

于 2013-03-15T13:59:52.033 に答える