アプリケーションでデータベースを共有したり、Webサービスとの同期を維持したりできますか？
ユーザー認証とユーザー管理用に個別のアプリケーションを構築することにしました。その理由は、前者は「これは常に機能する必要があり、即座に実行する必要がある」スタイルのサービスであり、後者は多くの要件と機能を備えたはるかに大きなユーザーインターフェイスコンポーネントが含まれているためです。
残念ながら、ホワイトボード、プロトタイピング、および必要な機能に関する詳細情報の取得中に、いくつかの種類の情報を共有する必要があることを発見しました。たとえば、どちらのアプリも、ユーザーがロックアウトされているかどうか、またはパスワードをリセットする必要があるかどうかを知る必要があります。
アプリケーションを同じデータベースに接続することを検討しています。通信にWebサービスを使用することを検討しましたが、それは先行費用が高くなり、より複雑で、パフォーマンスが低下します（どちらの場合でも同じクエリが作成されると仮定）。 2つのデータベースインスタンス間でいくつかの情報を同期させる必要がありますが、これは明らかに最適な設定ではありません。
一方、データベースインスタンスを共有するには、ORMのエンティティスキーマをある程度同期させる必要があります（1つを使用していなくても、データベーススキーマが変更されるたびにクエリが両方のアプリで機能することを確認する必要があります） ）。共有依存関係を作成します。さらに、データベースは障害/パフォーマンスの単一点になります。さらに、無関係なデータをどちらのアプリからも隠すことができるかどうかは不明なので、カプセル化を減らします。
ここの誰かが以前にこのジレンマに取り組み、洞察を得ましたか？ここにはまだ考えていない他の考慮事項があると思います。さまざまなアプリケーションを中央データベースに接続することは珍しいことではありません。
編集（かなり後で）：
ほぼ2年後のこの話の結果、アプリケーションが1つにマージされました（同じフレームワークを使用する単なるモジュールであったため、ありがたいことに簡単でした）。当時、これらを2つに分割する理由は理にかなっていますが、振り返ってみると、多くの責任がありすぎて実用的ではありません。
要するに、オールインワン。
これらの1つを「マスター」と見なし、もう1つを拡張レプリカと見なすと、その更新は一方向にのみ複製され、同期で大きなレイテンシを乗り切ることができます（「大きな」と定義します）、2つの個別のDB動作します。それ以外の場合は、単一のDBをお勧めします。
双方向の更新がある場合、それらは同期または非同期になりますか？前者とあなたは2つのDBを密接に結合しています。後者とあなたは複雑さを増すために適切な衝突解決策を持っている必要があります。単一のDBを使用することで、同時実行テクノロジーの豊富なサポートを受けられます。
ミリ秒またはマイクロ秒であっても、コピープロセスでは遅延が発生します。ただし、ソースのデータとレプリカのデータの間に不整合を導入するために必要なことはこれだけです。その後、全体の調整と解決が再び行われます。
DRをどのように扱いますか？異なるサーバー（またはデータセンター）上にある可能性がある2つのDB間で共通の同期点をどのように確保しますか？一致する2本のテープを毎回オフサイトの保管庫から確実に戻すにはどうすればよいですか？
テーブルまたは列を追加するスキーマの変更は、他のアプリケーションに対して透過的です。 （あなたは書いていませんSELECT *、あなたは？ ARE YOU？）オブジェクトの削除shouldは、そのときに使用するモジュールにのみ影響します。 （1つの冗長テーブルを持つ2つのDBは他の匂いから削除されますが、私には大きな混乱の潜在的な原因のようです。）ビジネスルールが変更されたためにスキーマを変更すると、作業が重複する可能性があります。しかし、1つのアプリケーションがそのビジネスルールを実装していない場合は、とにかくDBのその部分に呼び出す必要がなかったようです。
ORM実装コードファイルを、両方のアプリケーションに共通にする方法で保存できますか？その後、スキーマの変更は1セットのコードにのみ影響します。
「単一障害点としてのデータベース。」さて、フェアポイント。しかし、それはそれが私がこれまで取り組んできたすべてのアプリケーションに絶対にありました。そのため、DBMS製品にはクラスター/ミラー/高可用性が組み込まれています。 2つのDBがあり、1つが失敗した場合、どうなるでしょうか。調整/競合解決サイクルに戻ります。また、チューニングの単一ポイントでもあります。 1つの場所で修正すれば、どこでも修正されます！
ビュー、ストアドプロシージャ、ORM自体、およびすべてのSELECTクエリのアイテムを制限することで、アプリケーションのどの部分も関係のないデータから分離できると思いました。
あなたの質問の私の読みは、あなたの2つのアプリケーションは実際には非常に密接に結合されているということです。私の反応はそれによって色づけされます。データを一括コピーまたは双方向複製してその結果に対処するシステムをたくさん書いてきました。
考慮すべきことは、マスターデータ管理（MDM）アプローチかもしれません。これは基本的に、各アプリケーションの運用データストアで構成され、それぞれがマスターデータストアと同期するためにETLジョブまたはレプリケーションを使用します。
各運用データストアスキーマは独立して展開でき、ETLジョブは必要な変換を処理します。同期の頻度と方向は、要件によって異なります。
このパターンは、データウェアハウジングのシナリオでよく使用されますが、トランザクションデータでも機能します。アプリケーションまたはWebサービスを運用データストアの前に配置します。必要に応じて、レポートまたはその他のダウンストリームサービスがマスターデータストアから消費する可能性があります。
利用可能ないくつかの商用MDMソリューションが利用可能で、以下を提供できます。
- 追加機能
- アーキテクチャの柔軟性
- 安心
- データの整合性
- スケーラビリティ
ただし、このパターンは、商用のMDMソリューションまたはツールなしでも実装できます。データベースは操作可能でマスターとして指定され、データベース間でデータを移動するために必要なレプリケーションジョブを構築する必要があります。
特定の実装が何であれ、このパターンは2つの運用スキーマを互いに分離するのに役立ちます。
以前は同様のアプリケーションで作業していましたが、アプリケーションで予想される状況は、このサイト、Facebook、Twitter、またはアプリケーションの動作方法とは大きく異なります。
これは念のためですが、これにより多少の洞察が得られます。認証データとビジネスデータの両方を同じSQLデータベースに配置しました。理由は次のとおりです。
- アプリケーションが大きくなり、1台のサーバーでは不十分な場合、エンタープライズSQLベンダーは常に、DBが分散して動作する方法を抽象化するクラスターソリューションを提供します。シングルポイント障害やパフォーマンスの低下について心配する必要はありません。
- データスキーマを変更した場合でも機能するようにするには、スキーマが安定している必要があります。あなたはあまりにも多くを求めています。
- 両方を同じSQLサーバーサービスに含めることで、ユーザーアクセス権の同時変更に対処する必要があるすべての頭痛を軽減できます。ユーザーからのリクエストがバックエンドサービスに届いたときに、誰かがそのユーザーのアクセス制御値を変更するとします。
私のアプリケーションでは、少数のユーザーと大量のデータを期待していることに注意してください。ユーザー数が膨大な場合（ビジネスデータと比較した場合でも）、このWebサイト、Facebook、Twitter、またはアプリケーションの邪魔にならない