個別のリリースサイクルを持つ2つのアプリケーションが1つのデータベースを共有する必要があります

Question

2つの製品があります。

1. BIレポート（ビジネス情報）
2. ソーシャルネットワーキング

製品「ソーシャルネットワーキング」はWebアプリケーションであり、企業のユーザーが協力できるようにします。

両方の製品が共有するデータベースが1つあります。彼らはそれぞれデータベースに独自のテーブルを持っており、いくつかの「ユーザー管理」テーブルも共有しています。

各製品には独自のリリースサイクルがあります。「ソーシャルネットワーキング」の新しいバージョンをリリースすると、「BI Reports」の新しいバージョンを常にリリースするとは限りません。

顧客が「BI Reporting」のバージョン「X」と「ソーシャルネットワーキング」のバージョン「Y」のバージョンを持っている場合、データベースのアップグレード/バージョン化に関する頭痛があります。内部的には、データベースには2つのバージョンがあります。

最良のアイデアはデータベースを2つに分割することだと思います。各製品は独自のデータベースを取得し、「ソーシャルネットワーキング」は「BI Reports」が提供するWebサービスを通じてユーザー管理情報を取得します。しかし、私のチームの残りの部分は、これはあまりにも多くの仕事であり、アイデアが気に入らないと考えています。

複数のアプリケーション間でデータベースを共有することに関する経験はありますか？

Answer 1

いくつかの異なるモジュールで構成される製品があります。顧客は、どのモジュールをインストールしているかを選択できます。

すべてのモジュールは、ユーザーログインやその他の非常に一般的なサイト全体の機能を処理するコアピースを共有しています。

これを複雑にすることは、一部のモジュールが他のモジュールに依存していることです。大量のコードを簡単に撮影し、新しいモジュールを簡単に構築するために、モジュール式アプローチを取りました。

とはいえ、各モジュールがバージョンにされ、潜在的に個別にリリースされる可能性があるという点で、同様の状況があります。これを処理するために、私たちは2つのことをしました。

まず、各モジュールは、現在の改訂番号を持つ共通のDBテーブルに登録されています。また、セキュリティの役割とアクションを共通のテーブルに登録します。これらのチェックは、コアがそれを処理できるほど十分に一般的です。第二に、各モジュールにはデータベース内に独自のスキーマがあります。 IE：module1.table1、module2.table2。これにより、複数のモジュールで同じテーブル名を持つことができます。

特定のモジュールをアップグレードすると、独自のDDL（Structure/Data/S'Procs/Views）のみに影響します。モジュール間に依存関係がある場合、これはアップグレードツールによって処理されます。データベースをチェックして、関連するモジュールのバージョンxyz（またはより良い）がインストールされているかどうかを確認します。それがある場合、アップグレードは継続することが許可されています。そうでない場合は、アップグレードが中止し、最初に他のパーツをアップグレードする必要があるユーザーに伝えます。

これを奪う主なことは、依存関係チェックです。モジュールが真に個別であり、共通のセキュリティチェックのみを共有している場合、それほど重要ではありません。ただし、他のオーバーラップがある場合は、それぞれのインストーラーがバージョンを確認して互換性があることを確認する必要があります。

同期していない人のために、両方のアプリを現在のレベルにアップグレードする「完全な」インストーラーを提供することもできます。

Answer 2

これが管理上の決定である場合、私は次のようにアプローチします：

1. システムを管理するのにどれくらいの時間/リソースが必要ですか？

2. システムを提案された新しいシステムに再加工するのにどれくらいの時間/リソースがかかりますか？

3. 変更が行われたときにシステムを管理するのにどれくらいの時間/リソースがかかりますか？

変更を加えることでいくつかのリソースの節約があると仮定すると、投資収益率があるカットオーバー期間があるはずです。マネージャーは、今後の時間の長さが、優先される必要がある他のアイテムとその努力の現在の費用に値するかどうかを判断できるでしょう。

Hth

Answer 3

これはリリースサイクル以上のものに触れていると思います - 私たちはこれについてかなり自分自身について考えています。

当社のカタログアプリケーションにもBIの側面がありますが、BI部分がカタログのパフォーマンスに影響している可能性があることがわかりました。

これは、2つのアプリケーションの分離データベースが、リリース管理だけでなくパフォーマンスのためにも機能する可能性があることに気付くかもしれません。 Social -NetowrkingアプリからBIアプリへの主要なデータの定期的な「アーカイブ」は、ソーシャルアプリとリリース管理のパフォーマンスである両方の世界で最高の世界を提供する可能性があります。

あなたのための共有されたユーザー管理の側面についてはわかりません...

Answer 4

共有テーブルを変更する場合は、両方のアプリを更新する必要があります。別のリリースサイクルを持つことはできません。

これは明らかです....いいえ？