アプリケーションごとに1つのデータベースを使用するか、複数のアプリケーション間で単一のデータベースを共有する必要があります[終了]

同じソースからのデータを使用するアプリケーションが複数あります。ベストプラクティス（または賛否両論）は次のとおりです。

• 複数のアプリケーションで共有されるデータベースにデータを残す

  1. 必要なデータベースは1つだけなのでスペースを節約できます
  2. アプリケーションごとにクエリのニーズが異なるため、インデックス作成が複雑になります

• データをアプリごとのデータベースに毎日インポートする

  1. 重複データがアプリごとのデータベースに存在するため、より多くのスペースを使用します
  2. 各アプリが個々のニーズに集中できるため、インデックス作成が簡単

他の長所/短所を省いたかもしれませんが、もしあれば、あなたの職場でどのようにこれを行っていますか？

最近はスペースが安いため、アプリケーションごとに1つのデータベースを使用することをお勧めします。

複数のアプリケーション間で1つのデータベースを共有することには、いくつかの重大な欠点があります。

• より多くのアプリケーションが、それはあなたがいることである可能性が高い、同じデータベースを使用して、パフォーマンスのボトルネックをヒットし、あなたがいることを、必要に応じて簡単に負荷をスケーリングすることはできません。SQLデータベースは実際にはスケーリングしません。より大きなマシンを購入することはできますが、クラスター内でうまく拡張できません！

• メンテナンスと開発のコストが増加する可能性があります。アプリケーションが、手元のタスクには適していないが既に存在するデータベース構造を使用する必要がある場合、開発は難しくなります。また、1つのアプリケーションを調整すると、他のアプリケーションに副作用が生じる可能性があります（「なぜそのような不必要なトリガーがあるのか​​??！」/「そのデータはもう必要ない！」）。開発者がすべてのユースケースを知らない/わからない場合、1つのアプリケーションに1つのデータベースを使用することはすでに困難です。

• 管理が難しくなります：どのオブジェクトがどのアプリケーションに属しますか？カオスが上昇しています。データをどこで探す必要がありますか？どのユーザーがどのオブジェクトと対話できますか？誰に何を付与できますか？

• アップグレード：それを使用するすべてのアプリケーションの最小公分母であるバージョンが必要になります。つまり、特定のアプリケーションは強力な機能を使用できません。古いバージョンを使用する必要があります。また、開発コストも少し増えます。

• 並行性：プロセス間に時系列の依存関係がないことを本当に確認できますか？あるアプリケーションが古いデータを修正した場合、または最初に別のアプリケーションによって変更されるべきだった場合はどうなりますか？同じテーブルで同時に動作する異なるアプリケーションについてはどうですか？

それと比較して、データのインポート/ ETLプロセスはほとんどの場合非常に簡単で単純です。必要なだけデータをロードします。スペースは安価です。各アプリケーションのスケーラビリティを個別に考慮し、必要に応じて構造を調整および調整すれば、同時実行の問題は発生しません。副作用もはるかに簡単に追跡できます。

編集： ただし、@ Saeedが述べたように、一般的に利用可能なサービスでデータ操作をカプセル化できる場合、1つのデータベースを複数のアプリケーションで共有する方が簡単です。生のアクセスを必要としない限り、これは非常に良いアプローチです。

かつて同様の状況がありました。私の問題は、在庫管理用、調達管理用、ユーザー管理、つまり従業員用の3つのアプリケーションを構築することでした。データベースをアプリケーションごとに物理的に分割したり、アプリケーションごとに物理的に結合したりしないことをお勧めします。むしろ、私見の論理的分離の方がうまく機能します。

たとえば、3つのアプリケーションすべてが従業員情報を処理する必要がありました。在庫システムと調達システムの両方が、商品と在庫品目の同じ情報を使用していました。

共有データベースを作成し、そこにユーザーと商品の情報を保存しました。次に、その上にサービスレイヤーを構築し、それらのサービスを他のアプリケーションで使用しました。たとえば、現在会社にいるすべての従業員のリストを表示するには、サービスのようなメソッドを呼び出すだけで済みますGetOnWorkEmployees()。

また、ユーザーや商品とやり取りするための共通UIを作成しました。これは、それ自体が別個のWebアプリケーションでした。

したがって、@ Falconが指摘したものに加えて、1つのデータベース内のアプリケーション間で共通の機能を一元化することでメリットが得られると思います。

これらのアプリケーションが同じデータ（たとえば、製品と顧客の同じリスト）から機能することを意図している場合は、データベースをまとめます。データベースを分離しても何も得られません。これは純粋に「人間」の問題です。サーバーにとっては、ディスク上のバイトだけです。データベースが1か100かは関係ありません。ただし、分割する場合は、データの同期を処理する必要があります。インデックス作成の問題は、実際の問題ではありません。dbが分割された場合、インデックスの維持に同じ量のプロセッサ時間を費やすことになります。

パフォーマンスが問題になり始めたら、dbを複数のサーバーに複製してバランスを取ります。

状況によってはトレードオフの価値がある場合とない場合がありますが、単一のデータベースを使用するとデータの整合性を維持しやすくなります。少なくともMS SQL Serverでは、あるデータベースのキーを別のデータベースに外部キーすることはできません。トリガーを使用して外部キーの動作をシミュレートできますが、特にエレガントではありません。

さらに、データのローカルコピーを作成すると、書き込みが発生したときに危険になる可能性があります。AppAとAppBの両方にいくつかの共有データのコピーがあり、AppAがそれを更新する場合、AppBは引き続き古いデータを保持します。または、データの同期を保つためにトリガーを設定する必要があります。

かつて私は複数のウェブサイトを持っていて、それらは時間とともに人気を集めました。主にホスティングプロバイダーがそれぞれ1 GBのストレージスペースしか許可していないため、彼らは別々のデータベースを使用しました。しかし！これらのすべてのWebサイトを含むサービスをリリースするとすぐに、これらのWebサイト間でトランザクションを行う必要がありました。これを行う最も便利な方法は、すべてを1つの大きなデータベースに移動することです。

そのため、データベース構造を最適化し、関連する部分をこの中央データベースに絞り込みましたが、その他はすべて省略しました。

私の意見は、何らかの形でOOPのパラダイムに関連しています。同様のデータを一緒に保存する必要があるため、異なるアプリケーションを構築する場合は、それらに異なるデータベースを使用する必要があります。

上記の場合、一般的なデータベースの使用は避けられませんでしたが、一般的なクエリの一部ではない別のデータベースにいくつかのテーブルを置いておくことに注意してください。

さらに、それらを分離しておくと、バックアップが容易になり、データ損失の可能性が低くなります。何かがうまくいかず、アプリケーションが相互に干渉する場合、データベースは台無しになり、基本的にアプリをこの危険にさらしたくないでしょう。

全体として、一般的なクエリに対して共通のデータベースを維持できますが、アプリケーションごとにデータベースを保持することもできます。

アプリケーションアーキテクチャについて詳しく説明していただけますか？

データベースがトリガーやビジネスパッケージコードなどのアプリケーションロジックのないデータリポジトリとして機能する場合は、単一のデータベースを用意し、すべてのアクションにデータベースを使用するサービスにビジネスレベルの機能をカプセル化することをお勧めします。データベーススキーマにトリガーまたはコードがある場合、多くの場合に面倒な単一のデータベースを使用することで大きな問題に直面します。