アプリケーションごとに1つのデータベースを使用するか、複数のアプリケーション間で単一のデータベースを共有する必要がありますか
同じソースのデータを使用するアプリケーションがいくつかあります。以下がベストプラクティス（または賛否両論）ですか？
複数のアプリケーションで共有されているデータベースにデータを残す
- 必要なデータベースは1つだけなので、スペースを節約できます。
- 異なるアプリケーションには異なるクエリのニーズがあるため、インデックス作成が複雑になります。
アプリごとのデータベースに毎日データをインポートする
- 重複データがアプリごとのデータベースに存在するため、より多くのスペースを使用します
- 各アプリが個々のニーズに集中できるため、インデックス作成が容易
他の長所/短所を省略している可能性があります。もしあれば、あなたの職場でこれをどのように行っていますか？
最近はスペースが安いので、アプリケーションごとに1つのデータベースを使用することをお勧めします。
複数のアプリケーション間で1つのデータベースを共有すると、重大な欠点が発生します。
同じデータベースを使用するアプリケーションが多いほど、パフォーマンスボトルネックに陥るであり、必要に応じて負荷を簡単にスケーリングできないである可能性が高くなります。 SQLデータベースは実際にはスケーリングしません。より大きなマシンを購入することはできますが、それらはクラスター内で十分に拡張できません！
メンテナンスと開発のコストが増加する可能性があります：アプリケーションが、現在のタスクに適していないデータベース構造を使用する必要があるが、すでに存在しているため使用する必要がある場合、開発は困難になります。また、1つのアプリケーションの調整が副作用を他のアプリケーションに及ぼす可能性もあります（「なぜそのような不必要なトリガーがあるのですか??！」/「そのデータはもう必要ありません！」）。開発者がすべてのユースケースを知らない/知らない場合、単一のアプリケーション用の1つのデータベースではすでに困難です。
管理が難しくなります：どのオブジェクトがどのアプリケーションに属していますか？カオス上昇。データはどこで探す必要がありますか？どのユーザーがどのオブジェクトを操作できるか？誰に何を付与できますか？
pgrading：バージョンを使用するすべてのアプリケーションの共通の最小要素であるバージョンが必要です。つまり、特定のアプリケーションは強力な機能を使用できなくなります。古いバージョンを使い続ける必要があります。また、開発コストも少し増加します。
Concurrency：プロセス間に時系列の依存関係がないことを本当に確認できますか？あるアプリケーションが古いデータを変更した場合、または最初に別のアプリケーションによって変更されたはずのデータはどうなりますか？同じテーブルで同時に動作する異なるアプリケーションについてはどうですか？
それと比較して、データのインポート/ ETLプロセスは、ほとんどの場合、かなり単純で単純です。必要なだけデータをロードしてください。スペースは安価です。各アプリケーションのスケーラビリティを個別に考慮し、必要に応じて構造を調整および調整することができ、同時実行性の問題は発生しません。副作用もはるかに簡単に追跡できます。
編集：ただし、@ Saeedが述べたように、一般的に利用可能なサービスでデータ操作をカプセル化できれば、1つのデータベースを複数のアプリケーションと共有する方が簡単です。直接アクセスする必要がない限り、これは非常に良いアプローチです。
一度は似たような状況がありました。私の問題は、3つのアプリケーションを作成することでした。1つは在庫管理、1つは調達管理、もう1つはユーザー（つまり従業員）を管理するためのものです。アプリケーションごとにデータベースを物理的に分割したり、アプリケーションごとにデータベースを物理的に結合したりしないことをお勧めします。むしろ、IMHOの論理的分離のほうが効果的です。
たとえば、従業員情報を操作するために必要な3つのアプリケーションすべて。在庫システムと調達システムの両方が、商品と在庫アイテムの同じ情報を使用していました。
ユーザーと商品の情報を保存する共有データベースを作成しました。次に、その上にサービス層を構築し、それらのサービスを他のアプリケーションで使用しました。たとえば、現在会社にいるすべての従業員のリストを表示するには、GetOnWorkEmployees()のようなサービスからメソッドを呼び出すだけで済みます。
また、ユーザーと商品を操作するための共通のUIも作成しました。これは、それ自体が独立したWebアプリケーションでした。
したがって、@ Falconが指摘したことに加えて、アプリケーション間で共通の機能を1つのデータベースに集中化することでメリットが得られると思います。
これらのアプリケーションが同じデータ（たとえば、製品と顧客の同じリスト）で機能することを意図している場合は、データベースをまとめて保持します。データベースを分離しても何も得られません。これは純粋に「人間の」問題です。サーバーにとっては、ディスク上のちょうどそのバイト数です。データベースが1か100かは関係ありません。ただし、分割する場合は、データの同期を処理する必要があります。実際に発生するインデックス作成の問題は、実際の問題ではありません。データベースが分割されている場合、インデックスの維持に同じ量のプロセッサ時間を費やすことになります。
パフォーマンスが問題になり始めた場合は、dbを複数のサーバーに複製して、バランスをとります。
状況によってはトレードオフの価値がある場合とない場合がありますが、単一のデータベースを使用するとデータの整合性を維持するのが簡単になります。 MS SQL Serverでは、少なくとも、あるデータベースから別のデータベースへの外部キーは使用できません。トリガーを使用して外部キーの動作をシミュレートできますが、特にエレガントではありません。
さらに、書き込みが行われるときに、データのローカルコピーを作成すると危険な場合があります。 AppAとAppBの両方に共有データのコピーがあり、AppAがそれを更新した場合、AppBには古いデータが残っています。または、データの同期を保つためにトリガーを設定する必要があります。
かつて複数のWebサイトがあり、そのうち人気が高まりました。主にホスティングプロバイダーがそれぞれ1Gbのストレージスペースしか許可しなかったため、彼らは別々のデータベースを使用しました。だが！これらすべてのWebサイトを含むサービスをリリースするとすぐに、これらのWebサイト間でトランザクションを実行する必要が生じました。これを行う最も便利な方法は、すべてを1つの大きなデータベースに確実に移動することです。
そのため、データベース構造を最適化し、関連する部分をこの中央データベースに絞り込みましたが、その他はすべて省略しました。
私の意見は、どういうわけかOOPのパラダイムに関連しています。同様のデータは一緒に保存する必要があるため、異なるアプリケーションを構築する場合は、それらに異なるデータベースを使用する必要があります。
上記の場合、共通のdbを使用することは避けられませんでしたが、共通のクエリの一部ではないいくつかのテーブルを別のdbに分けて保存したことを思い出してください。
さらに、それらを分離しておくと、バックアップが容易になり、データ損失の可能性が低くなります。何かがうまくいかず、アプリケーションが相互に干渉すると、データベースがめちゃくちゃになり、アプリをこの危険にさらしたくないでしょう。
全体として、一般的なクエリ用の一般的なデータベースを維持できますが、アプリケーションごとに1つのデータベースを保持することもできます。
アプリケーションアーキテクチャについて詳しく説明できますか？
トリガーやビジネスパッケージコードなどのアプリケーションロジックなしでデータベースがデータリポジトリとして機能する場合、単一のデータベースを用意し、すべてのアクションにデータベースを使用するサービスにビジネスレベルの機能をカプセル化することをお勧めします。データベーススキーマにトリガーまたはコードがある場合、多くの場合面倒な単一のデータベースを使用することで大きな問題が発生します。