1

これは広すぎるかもしれませんが、私が対処するのに時間がかかっている問題です。エンドユーザーに配布するアプリケーションがあります。derby バックエンド上で実行されています。コードの変更をかなり簡単にプッシュすることができます。それはサーバーに送信され、新しいバージョンがあることを確認し、ダウンロードして古いコードを上書きし、再起動します。

ただし、コードを変更すると、derby データベースのスキーマも変更されます。これを更新する優れた方法はありません。現在、FTP 経由で SQL 更新をプッシュできます。プログラムがインターネットに接続されると、新しい SQL ファイルが検索され、ダウンロードされて実行されます。

残念ながら、クライアントの多くはインターネット アクセスが制限されているため、これらの更新プログラムを断続的に入手しています。変更が十分に大きいために、ローカル DB スキーマが必要なものと同期しなくなることがあります。または、コードの変更は CD で入手できますが、SQL の変更は入手できません (誰かが CD を郵送します)。

私が試みたのは、スキーマの XML 表現を提供できる SOAP サービスを作成することです。これまでに開発するのは巨大な PITA でした。

このようなデータベースを維持するために人々が現在使用している方法は何ですか? これを行うのは私が初めてではないように感じるので、私がしていることよりも良い方法があるかもしれません.

ここでのいくつかのコメントに基づいて、ここに更新があります: 基本的に、DB の厳密なバージョン管理に準拠していないことで、早い段階で自分自身を台無しにしたと思います。多くの人がカスタム インストールを作成しました (意のままにうめきます)。彼らの DB と「公式」コピーの違いを見分けることができるツールが必要です。

ツールを作成しましたが、ある程度は機能しますが、追跡しなければならないことが…たくさん…あります。

4

3 に答える 3

3

コード変更の一部としてDB変更を配布できますか?次に、アプリが再起動すると、DBで更新を実行する必要があるかどうかを確認します。

明らかに、同じ更新を複数回適用しないように、DBスキーマをバージョン管理する必要があります。

私はこれを行ういくつかのアプリケーションを知っています(主にRubyで、しかしJavaでも)。

于 2012-08-03T15:56:11.060 に答える
2

インストールされているソース コードを変更するプログラムをダウンロードできるアプリケーションの更新メカニズムが既にある場合は、そのアップグレード プロセスの一部としてスキーマの変更をパッケージ化して実行してみませんか? その場合、更新を Java アプリケーションの一部として実行するだけです。

私の職場のチームは、MyBatis 移行ツールを使用してこれらの変更を処理します。このツールは、各スキーマ変更を「変更」と「ロールバック」のステップを含む単一の移行スクリプトとして表します。データベースに適用された更新を一覧表示するchangelogテーブルがデータベースに保存されます。これにより、migrateコマンドの実行時に適用する必要がある更新を簡単に判断できます。この特定のツールは、データベースを制御し、シェル コマンドとスクリプトを実行してデータベースを変更する機能を備えている場合にのみ、おそらく本当に役立ちますが、同じ概念をアプローチで使用できます。各スキーマ変更をアトミック ユニットとしてパッケージ化して実行します。プログラム内から、スキーマを現在のバージョンに引き上げます。これは、データベース自体で追跡できます。

于 2012-08-03T15:57:45.397 に答える
0

ユーザーが実行しているデータベースのバージョンを含むテーブルが必要です。次に、バージョン n からバージョン n+1 にアップグレードするためのコードが必要です。スキーマの変更を行うためのアクセス権を持つデータベース ユーザーがいると仮定すると、コードの変更を適用するのと同じ方法でスキーマの変更を適用できます。

于 2012-08-03T15:57:10.420 に答える