2

テスト データベースのデータを使用するテスト サーバーがあります。テストが完了すると、ライブ データベースに移動されます。

問題は、現在運用中のデータに依存する他のプロジェクトがあるため、必要なテーブルからデータを取得し、テスト DB のデータを削除し、ライブ DB からデータを挿入するスクリプトを実行する必要があることです。

このモデルを改善する方法を見つけようとしています。データは週に 1 回か 2 回しか更新されないため (私の側では何もしなくても)、移行の問題はそれほど大きくありません。問題は、移行が必要な場合にのみ行われることです。移行スクリプトにライブ テーブルとテスト テーブルに対するクイック チェックを含め、必要に応じて移行したいと考えています。更新がない場合、スクリプトは終了します。

このようにして、更新スクリプトを他のスクリプトに含めることができ、データが同期しているかどうかを心配する必要はありません。

タイムスタンプが使えません。1 つには、いったんライブになるとライブ側のテーブルを制御できません。また、利便性のためにテーブルをさらに大きくするのは少しばかげているように思えるからです。

「SHOW TABLE STATUS FROM liveb」を実行してみましたが、テーブルはすべて InnoDB であるため、「更新時間」はありません。さらに、「作成時間」は今朝だったようで、データベースがバックアップされていると思われます。毎日アップして再作成します。

2 つのうちどちらが新しいかを示す他のプロパティはテーブルにありますか? おそらく「最新の行の日付」ですか？

4

3 に答える 3

2

つまり、アプリケーションで開発ライブ更新をファーストクラスにします。データベースエンジンに依存して、決定を下すために必要な情報を提供するのではなく（更新するかどうか...それが問題です）、アプリケーションの一部として実装するだけです。それ以外の場合は、丸いペグを四角い穴に合わせようとしています。

データモデルが何であるかを知らず、同期モデルが何であるかをまったく理解していない場合、いくつかのオプションがあります。

  1. 主キーをライブデータベースとテストデータベースと照合します。>ライブIDをテストする場合は、更新を行います。
  2. テーブルのタイムスタンプを使用して、更新する必要があるかどうかを判断します
  3. データベーステーブルのmd5ハッシュと変更日（UTC）を使用して、テーブルが変更されたかどうかを判断します。

簡単に言うと、データベースの同期は非常に困難です。アプリケーションに固有のソリューションを実装します。理想的に機能する「一般的な」ソリューションはありません。

于 2009-06-09T04:40:23.363 に答える
0

独自のソリューションを作成するのではなく、データベースの同期を維持するための既存のソリューションを使用できます。SQLYogのSJAについて良いことを聞いたことがあります（ここを参照）。自分で使ったことはありませんが、他のプログラムにはとても感動しました。

于 2009-06-09T04:40:05.500 に答える
0

テーブルに自動インクリメントがある場合は、自動インクリメントの最大値を比較して、それらが異なるかどうかを確認できます。

しかし、どのバージョンの mysql を使用していますか?

于 2009-06-09T04:31:26.597 に答える