新しいアプリケーションのデータベースを設計するためのオプションを考え、検討しています。一般的に、私は登録ユーザーとそれらに関する情報を持っています。彼らはアプリでいくつかのことを行うことができ、そのデータはユーザーデータとして sam DB に保存されます (そのため、FK の共有などを行うことができます)。
しかし、次に、ユーザーIDをFKとして共有することを除いて、最初のデータベースから完全に独立したロジックになる2番目のデータベースを用意する予定です。
その 2 番目のロジックを追加の DB に配置する必要があるのか 、それともすべてを同じデータベースに配置する必要があるのか わかりません。2 番目のロジック (アプリ内のアプリのようなもの) のためにアプリにサブドメインを含める予定ですが、より多くのデータを共有する必要があることがわかった場合はどうすればよいですか? そのクロスクエリはパフォーマンスを低下させますか? データベースを分離する本当の理由はありますか?
2 つのデータベースがあるとすぐに、複雑になる可能性があります。2 つのデータベースが必要な理由は特にありません。そのため、理由がわかるまではシンプルに保ちます。
人々が行っていることの例: 「現在の」データベースを小さく、現在必要なデータだけを保持します。それは、注文を受けて履行される場所かもしれません。データが最新ではなくなったら、たとえば、注文が完了してから数日または数週間後に、データを「履歴」データベースに移動します。そこでは、マーケティングや管理の担当者は、「現在の」データベースのパフォーマンスに影響を与えることなく、履歴の全体的な傾向を見ることができます。データベースのパフォーマンスは、顧客を満足させ続けるために重要な場合があります。
複雑さの例: 2 つのデータベースがあり、それらの間の一貫性を考慮する必要がある場合、これを保証するのは見た目よりもはるかに困難です。データベースは 2 フェーズ トランザクション機能を提供します。また、バッチ プロセスを考案することもできますが、把握するのが難しい微妙な点が常にあります。
また、データの量が膨大にならない限り（質問から判断すると、ここではそうではないようです）、単一のデータベースを使用してパフォーマンスの問題なしにデータを保存できることにも同意してください。
データ構造を「視覚的に」分離するために、単一データベースの 2 つのスキーマにテーブルをいつでも作成できます。
すべてを1つのデータベースに保持するだけです。何十ものテーブルがない限り、実際のパフォーマンスの問題はないはずです。ただし、1 つのデータベース接続で作業するだけで済み、2 つのクエリからの情報をマージすることを心配する必要がなく、生活が大幅に楽になります。