マルチアプリケーションシステムで共通テーブルを含むデータベースを適切に使用する方法
自分が取り組んでいるプロジェクトに最適なアプリケーションとデータベースアーキテクチャを決定しようとしています。
アイデアは、UserテーブルやEmployeeテーブルなどのいくつかのテーブルをすべて共有する複数の個別のアプリケーションがあるということです。各アプリケーションには、Web部分（サーバー側またはクライアント側のレンダリングに応じてAPIが必要になる場合があります）とiOS部分（APIが必要になります）があります。クライアント側のレンダリングに移動して何かを使用する場合Vue.js、React、Emberなど。 Web APIとiOS APIを統合できるかもしれません。 （補足：サーバーサイドレンダリングの方がはるかに快適であり、クライアントサイドに移動する場合はJSフレームワークを学習する必要がありますが、それが最善のオプションである場合は学習します。）
私は現在、この種のシステムを実装する方法について3つの異なるアプローチを持っています。それらはすべて、COMMON_DBと呼ぶ別のデータベース内の共通テーブルを分離します。
（オプション1が最後なので、最初のページから再描画する必要がありました。）
--------------------オプションのテキスト説明-------------------
オプション1：
システム内のすべてのデータベースとのすべての通信を行うAPIをGraphQLとともに使用します。 Webアプリケーションが2つある場合、APIには3つのデータベース、DB_APP_1、DB_APP_2、およびDB_COMMONが接続されます。共通データベースには、2つのアプリケーション間で複製/共有されるテーブルが含まれます。アプリケーション（App1およびApp2）はクライアントまたはサーバー側のサーバーであり、DB APIと通信して必要な特定の情報を取得します。
オプション2：
各アプリケーションは2つの異なるデータベースに接続します。アプリ1はDB_APP_1とDB_COMMONに接続し、アプリ2はDB_APP_2とDB_COMMONに接続します。 App1とApp 2はサーバー側になります（クライアント側またはサーバー側のレンダリングを介してクライアントをレンダリングするためのイーサネットAPI）
オプション3：
各アプリケーションは、共通APIサーバーと通信します。 Common APIサーバーには1つのデータベースがあり、これは各アプリケーションの共通テーブルです。各アプリには独自のデータベースがあり、データベースには各アプリケーションの一意のテーブルがすべて含まれています。各アプリケーションは、オプション2のような共通データベースに直接アクセスできません。繰り返しますが、アプリ1とアプリ2はサーバー側であり、クライアント側レンダリング用のイーサネットAPI、またはクライアントサーバー側レンダリングです。
私は現在、これらのアプローチのどれが最も有益であり、将来の障害を防ぐかについて自分自身と闘っています。期待されるべき新しい技術についてのいくらかの学習があるでしょう。
ご意見、ご感想をいただければ幸いです。不明な点やご不明な点がありましたらお知らせください。
ありがとうございました
私はオプション1が好きです。その場合、アプリは基盤となる永続化スキーマを認識せず、永続化管理はAPI（またはその下/内部のレイヤー）によって行われます。
一般的なルートは＃1オプションで、「これを取得」、「それを取得」などのインターフェースを持つリポジトリパターンを使用し、リポジトリの実装は、正しいデータベースからの情報のプル（および情報の保存）を扱います。
または、アプリごとに個別のAPIがあり、各APIは同じ場所にあるリポジトリをどこかに持っています。
オプション2と3で示されているように、アプリがデータベースと直接「対話」することは避けます。
（一般的に）各コンポーネントは一般的にその下のサービスの詳細に関係するべきではないことを覚えておいてください。
一般的に言えば、サービス/レイヤーがより分離されているほど、初期設定がより複雑になりますが、長期にわたって維持しやすくなる傾向があります。一方、非常に単純なアーキテクチャで開始すると、後で対処するのが非常に困難になる可能性があるため、プロジェクトに予想される寿命が何らかの種類である場合は、アーキテクチャへの投資を行う方がはるかに適しています。
これには多くのバリエーションがあります（そして、マイクロサービスのようなことをしている場合は、まったく異なる領域にいます）が、基本的なポイントを理解するための簡単なビジュアルを次に示します。
複数のデータベースに展開された共通のテーブルが必要だと思っています。これは私に関係があります。
アプリケーション層を複数のアプリケーションに分離することから始めるのがよいでしょうが、データベースを分離することが最初のステップではありません。
1つのデータベースを作成します。 「共通」テーブルは「共通」スキーマに入ります。各アプリケーションは独自のスキーマを取得し、共通スキーマのテーブルへの外部キー参照を保持できます。
そこから、アプリケーション層を自由に好きなだけ多くのアプリやAPIに分割できます。
データベースのパフォーマンスが問題になる場合は、データベースのシャーディングが可能なサーバーアーキテクチャから始めます。これは、負荷を分散するのに役立ちます。複数のサーバーが使用されているため、調整されたエコシステム全体でアプリケーションを新しいアップグレードされたデータベースに「再ポイント」することなく、ハードウェアをアップグレードできます。
1つのデータベースから始めます。個別のスキーマ。アプリケーション層を、必要と思われる数のレイヤー、API、マイクロサービスに分割します。データを再構築するよりもコードをリファクタリングする方がはるかに簡単です。特に、個別のデータベースサーバー内のデータは簡単です。
レポートのプルが非常に遅くなった場合は、「レポートデータベース」を追加します。結局のところ、四半期レポートには最新のデータは必要ありません。結果整合性はそのために問題ありません。
したがって、基本的にオプション1から3は、データベース部分を除いて問題なく見えます。それらすべてが同じDBを指すようにします。次に、好きなオプションを選択します。
コメントに応じた更新：
SegFaultDevはコメントしました：
MySQLでは、すべてのスキーマは同義語であるため、実際にはデータベースです（少なくともそれが私の理解です）。
最初のポイントは、データベース/スキーマ/テーブルのコレクション間の参照整合性を最初に許可することだと思います。どうしても必要な場合にのみ、完全に別のシステムに分割してください。 MySQLには、これに関する問題はありません。
アプリケーション層を複数のシステム（Webアプリケーション、Web API、マイクロサービス）に分割することは完全に問題ありませんが、データストレージメカニズムが1つのまとまりのある単位（「スキーマ」）である場合は、アーキテクチャ全体でより簡単な時間を確保できます。 OracleではMySQLまたはMySQLでは「データベース」。