複数のアプリケーションのための1つのデータベース？
複数の社内アプリケーションがすべて1つのデータベースの下にあり、各アプリケーションがその単一のデータベース内で独自のスキーマを与えられている環境で誰かが働いていますか？私は、1つのDB内のいくつかの小さな関連アプリケーションを意味するだけでなく、他のスタンドアロンアプリケーションと一緒に1つのDBに配置されるスタンドアロンアプリケーションのフルのようなものです。
私はずっと前から導入されているこのようなアーキテクチャを扱っており、新しいスタンドアロンアプリケーションを独自の個別のDBに配置する必要があると主張しようとしていますが、これは「すべてを1つにまとめる」と基本的に言われています「データベース」アーキテクチャは、個別のDBよりも理にかなっており、私は何と言ってもいいのか途方に暮れています。他の誰もこのように1つのデータベースに複数のアプリケーションを配置していないので、インターネットでこれについて多くの情報を見つけることができないように感じますが、多分私は完全に間違っていますか？
Microsoft SQL Serverおよび.NET Webアプリケーションを使用しています。
はい、同じような環境で働いています。
スキーマとデータベースの違いは、アプリケーションの観点からは大きな違いはありません。結局のところ、サーバー上のすべてのデータベースは同じサーバー上で実行されます。私はそれを発汗しないでしょう。
重要なことは、テーブル間の分離を維持し、1つのセットが別のセットを参照しないようにするか、ドメインにまたがるクエリを使用しないことです。
私はDBの設定をDBAに任せ、SQLが適切であることを確認しました。
要するに
私は両方の環境で働いてきました。私はシェアードDBアプローチの無条件の推進者でした。 limitations を確認して再考するには、少し時間がかかりました。同じ bounded context で動作する密接に関連するアプリケーションのみを想定してください。
一般に、shared-dbは非常にうまく機能します。それらの前のCOBOLプログラムのように。そして、それらと同様に、データの扱い方を知っている（そしてそれを正しく行う）ソフトウェアによって処理されるのを待つ受動的なものとしてデータを見るようにします。シングルdbには、アプリケーションでエンタープライズデータを共有できるという利点があります。正確には、グローバルデータはさまざまなモジュールで共有されます。
しかし、現代のソフトウェアエンジニアリングは、モジュールをカプセル化し、グローバルデータを回避し、OOの方法で実行することを学びました。データは、確実に処理できるコードと一緒にのみ意味があります。なぜ無視し続けるのかデータベースレベルでのこれらの原則
長い間
単一の企業データベースの蓄積
企業ではすべての活動が何らかの形でリンクされているため、単一データベースは非常にうまく機能します。これが、多くの主要なERPの背後にある原則です。すべてを1つのDBに格納すると、さまざまなアプリケーションをリアルタイムで簡単に統合できます。
利点：
- 運用コストの削減
- プロセスを再設計する機会：すべてのデータがそこにあります。したがって、アプリケーション間で機能を自由に再配布できます。
- Db設計を合理化する機会：80年代の終わりから90年代の初めに、アプリケーションソフトウェア（特にETL /インターフェイスプログラム）の数が大幅に減少した、いくつかの集中化プロジェクトを目にしました。
- 相乗効果：異なるチームが同じスキルを共有し、DBスキームを伝達することでアイデアを共有できます。
リスクとデメリット：
- 成功は、ドメイン全体でグローバルな視点からDBスキームを設計する能力に依存します。誰もが自分の名前空間に砂の城を構築し続けると、グローバルDBの不便さがその利点のほとんどなしに得られます。
- 強結合 コンポーネント：データが他の多くのアプリと絡み合っているため、別のコンテキスト（別のサイト、別の会社）でアプリケーションを再利用できなくなりました。
- 不明な依存関係：すべてが1つのDBでリンクされており、別のスキーマ/名前空間のテーブルに簡単にアクセスできるため、依存関係は明確ではありません。これはもちろん、開発の組織に影響を与えます。テストした一部のdbテーブルが別のアプリの開発者によって変更されていないことを確信していますか？どのように dbの進化を整理する ？
- 動作の悪いプログラムの1つがデータベース全体で不整合を引き起こす可能性があります
- スケーラビリティは、最終的にはDBエンジンのスケーラビリティによって制限されます。
- 恐怖のせいでイノベーションが減速するのか？不明な依存関係のため、ほとんどの場合、SWエンジニアは稼働中の本番データベースには触れないことを好みます。
- ベンダーロックイン？
しかし、今は別の世界にいるのではないでしょうか？
今日の傾向は、モノリスを避け、柔軟で進化的でスケーラブルなアーキテクチャを考案することです。
- 私たちのインターネット対応の世界では、アプリケーションはWebサービスを通じて通信でき、リアルタイムで交換するための共通のデータベースを必要としません。
- マイクロサービス アーキテクチャー 共有DBを回避する傾向がある ：各（マイクロ）サービスには 独自のプライベートDB が必要であり、デカップリングを増やす新しい開発の展開を加速します。
- クラウド運用では、まったく異なる角度での運用コストを再検討できます。パッチ、アップグレード、またはバックアップする必要があるdbsサーバーの数を気にする必要はありません。価格に含まれています。
- NoSQLはそれを主流への道にしました。多くのアプリケーションはRDBMSと完全に連携できます。しかし、さまざまなテクノロジーでより適切に処理される特殊な問題があります。グラフDB、ドキュメント指向のDB、または地理的ローカライズされたソートの必要性は、特殊なDBエンジンを好む場合があります。 One-DBポリシーはブロッカーになります。
- 一部のアプリケーションはDBを必要としません。たとえば、イベントストリームは、アプリケーション間で大量のデータをリアルタイムで処理します。dbでデータを共有する必要はありません（新しいdbを検出するには、非効率的な反復クエリが必要です）。
結論
優れたアーキテクチャの鍵は、単一のdbで適切なテーブルを定義することではなく、適切なAPIを定義して、サービスが異なるアプリ間を結合できるようにすることです。
これは言われて、独断的ではありません。同じ境界コンテキストで動作する密接に関連するアプリケーションの場合、共有DBは 有効な代替 のままです=。
私はまた、異なるデータベースが同じデータベースにある状況にありました。ご不便をおかけして申し訳ございませんが、「ベストプラクティス」が「良いビジネス」の対象となることもあります。
あなたが指摘したように、アプリが関連している場合、それらを同じDBに置くことは明らかに意味があります。ビジネス上の理由がある場合（他の回答や指摘されたコメントのように）、その理由を受け入れるか、それらを分離させることでより良いビジネス上の理由を作ってみることができます。 2つ考えられるのは、セキュリティ上の懸念とスケーラビリティです。今日では、多くのアプリが仮想化され、コンテナ化されています。 Docker化された（または使用するコンテナーアプリ）アプリと一緒に提供されるDockerコンテナーにDBを追加するのは簡単です。もちろん、このラインは、ライセンスやスタッフの費用が、必要に応じて別のコンテナを追加できることの利点を上回らないことを前提としています。
つまり、要約すると、それらのアーキテクチャは前例のないものではなく、実行されています。別の方向を提案したい場合は、彼らが彼らの決定を下した理由（技術的またはビジネス）を理解し、その領域に影響を与える議論をするようにしてください。