システムの各モジュールにデータベースを使用する
私は読んでいました this 質問：
各モジュールが独自の独立したモジュールデータベースを持つ3層アーキテクチャの概念を実装することにより、一部の機能（Eメール管理モジュール、CMSモジュールなど）を標準化およびモジュール化しようとしていました。そのため、将来的に必要なのは、プレゼンテーション層をコーディングし、BLL層、DAL層、およびデータベースを再利用することだけです。
私のフォローアップの質問は、各モジュールのすべてのデータベーステーブルを同じデータベースに配置するのが良いのか、それとも完全に別々のデータベースに分離する必要があるのかということです。私はPostgreSQLを使用しています。私の心配は：
- データが多くの異なるデータベースにある場合のデータ分析の実行に関する問題
- すべてのモジュールに同じデータベースを使用すると、データベースのパフォーマンスの問題を特定する際の問題
- 将来、特定の機能を作成するためのモジュール化に欠陥があることが判明した場合に、モジュール間でテーブルを結合する機能
何らかの方法で異なるモジュールからのデータを結合したい場合は、本当に単一のデータベースが必要です。
1つのデータベース内のものを区分化する適切な方法は schemas を使用することです：
- スキーマには個別の名前空間があるため、モジュールごとにスキーマを使用すると、モジュール間で衝突が発生しなくなります。
email.table1がcms.table1と衝突することはありません。 - 権限はスキーマレベルで設定できるため、たとえば、電子メールモジュールは電子メールセクションへのアクセスのみを許可できます。
データベースが1つしかないからといって、モジュールのインストール/削除に関して問題が発生することはないと思います。データベースのテーブルやスキーマを追加したり削除したりすることは、たいしたことではありません。
パフォーマンスについては、パフォーマンスの問題がある場合は、通常、ドリルダウンして、とにかく問題を引き起こしているクエリを確認する必要があります。 1つのデータベースにあるか、複数のデータベースにあるかにかかわらず、大きな違いはないと思います。
正しく行われれば、ビジネス上の懸念を異なるデータベース（または少なくとも異なるスキーマ）に分離することは美徳です。
Martin FowlerによるCQRSパターンの説明 を参照してください。
ニーズが高度化するにつれて、[情報システムをCRUDデータストアのように扱う]から着実に移行しています... CQRSが導入する変更は、その概念モデルを更新と表示のために別々のモデルに分割することです...かなりのバリエーションの余地がありますここに。インメモリモデルは同じデータベースを共有する場合があります。その場合、データベースは2つのモデル間の通信として機能します。 ただし、個別のデータベースを使用することもでき、リアルタイムのReportingDatabaseによってクエリ側のデータベースを効果的に作成します。この場合、2つのモデルまたはそれらのデータベース間に何らかの通信メカニズムが必要です。
そして NServiceBus Architectural Principles ：
コマンドクエリの分離
この問題を回避するソリューションでは、コマンドとクエリをクライアントとサーバーよりもシステムレベルで分離します。このソリューションには、クライアントとサーバーの両方にまたがる2つの「サービス」があります。1つはコマンド（作成、更新、削除）を担当し、もう1つはクエリ（読み取り）を担当します。これらのサービスはメッセージを介してのみ通信します-一方は他方のデータベースにアクセスできません...
コマンドとクエリの責任の分離
ほとんどのアプリケーションは、データを書き込むよりも頻繁にデータを読み取ります。そのステートメントに基づいて、データベースを簡単に追加して、そこから読み取ることができるソリューションを作成することは良い考えでしょうか？では、読書専用のデータベースを設定したらどうなるでしょうか。さらに良い;データベースの読み取りが速くなるようにデータベースを設計するとどうなるでしょうか。 CQRSアーキテクチャで説明されているパターンに基づいてアプリケーションを設計すると、スケーラブルでデータの読み取りが高速なソリューションが得られます。
- はい、一度に複数のデータベースを分析したい場合、問題になる可能性があります。すべてのデータを1つのanalysisデータベースに移行してマージし、そこで分析を行うことができます。つまり、テーブルと他のオブジェクト間の名前の衝突を回避するスキーマと、移行を実行するプロセスを設計する必要がありますが、それは実行可能です。
- はい、それも問題になる可能性があります。
- はい、それも問題になる可能性がありますが、各モジュールにデータアクセスAPIを持たせて、他の人がデータにアクセスできるようにすることもできます。これにより、データベース間で結合するクエリを作成することが困難になりますが、可能です。 Oracleではデータベースリンクも可能です（1つのデータベースでクエリを実行すると、別のデータベースのオブジェクトに直接アクセスできます）が、他のベンダーの製品について話すことはできません。
次に、モジュールごとに個別のデータベースを使用することで、それらがすべて正しく設定されていること、すべてが正しくバックアップされていることなど、追加のメンテナンス問題があります。
一方、実際に多くのモジュールがあり、それらがすべて一緒にデプロイされないシナリオを計画している場合、新しいデプロイメントをセットアップするときに、別々のデータベースを用意することは意味があるかもしれません。また、インストールが既存のデータベースにアクセスする必要がないことを確認できれば、新しいモジュールの追加が簡単になる可能性があります。