アプリケーションデータとユーザーデータに個別のデータベースを使用する必要がありますか？
私はしばらくプロジェクトに取り組んでいますが、どちらがより優れたアーキテクチャであるかわかりません。コンセンサスに興味があります。私への答えはかなり明白に思われますが、それについて何かが私を掘り下げており、私は何を選ぶことができません。
TL; DRは：アプリケーションデータとユーザーデータが同じDBにあり、アプリケーションデータの更新を定期的に受信する必要があるプログラムをどのように処理しますか？ユーザーデータ用の1つのデータベースとアプリケーション用の1つのデータベース、または両方を1つに統合しますか？
詳細なバージョンは..アプリケーションに、アプリケーションデータとユーザーデータを維持する必要があるデータベースがあり、ユーザーデータがすべてアプリケーションデータを参照している場合、それらを同じものに保存するほうが自然です。データベース。
しかし、このデータベース内のアプリケーションデータを定期的に更新できるようにする必要がある場合、これを2つのデータベースにストリップして、更新されたアプリケーションデータデータベースファイルを更新としてダウンロードし、古いものを置き換えることができるようにする必要がありますか？または、それらを1つのデータベースとして残し、既存のデータベースに新しいデータを挿入するスクリプトを使用してアプリケーションデータを更新する必要がありますか？ 2番目は明らかに私よりも好ましいように聞こえます...しかし、何らかの理由で正しくないと感じるだけで、なぜなのかまったくわかりません。
ユーザーデータベースとは独立してアプリケーションを移動する必要がある場合は、アプリケーション用に別のデータベースが必要です（どのような形式であっても）。これにより、データベースはアプリケーションと共に移動し、ユーザーデータは元の状態のままになります。ロケーション。
したがって、アプリケーションデータベースがベンダー（つまりあなた）から定期的に更新される場合は、ユーザーデータベースに影響を与えずにアプリケーションデータベースへの変更を配布できるように、ユーザーデータベースとは別に保持する必要があります。
ここで、ユーザーデータベースにフィールドまたはテーブルを追加する必要がある場合、それは別の話です。そのためには、アプリケーションデータベースからの変更のテーブルを入力として受け入れ、ユーザーデータベースに適用できるモジュールが必要です。一部のプログラムは、ユーザーデータベースを新しい形式に「変換」することによってこれを行います。
SQL DDLを使用してフィールドとテーブルの更新をユーザーのデータベースに適用することにより、ユーザーのデータに悪影響を及ぼさない方法でデータ変換を行うことができます。一部の高度なシナリオでは、データ変換が実際に行われる場合があります。たとえば、正規化または非正規化。
ユーザーにデータ転送を実行する機能を提供する必要がある場合は、通信コンジット、または転送されるデータ（おそらくXML）を含むインポート/エクスポートファイルなどの他のメカニズムを使用する必要があります。
それは本当に重要だとは思いません。別のデータベースにあるか同じデータベースにあるかに関係なく、必要に応じてアプリケーションデータを更新できる限り、他の要件を除外すると、あまり適切であるように見えません。 SQLスクリプトは、どちらの場合もテーブルをドロップ/リロードできます。
カップリングを見てみます。すべてのデータは一緒に属していますか？つまり、すべてのデータは（ドメイン主導の設計用語を使用するために）同じ境界コンテキストにありますか？そうでない場合、あなたはmayそれを分割したいと思います。
アプリケーションでは、物理的な場所は論理的な場所ほど重要ではありませんが、メンテナンス/パフォーマンスでは物理的な場所がかなり重要です。
これがある程度のレベルであなたを悩ませるという事実は、構造が快適ではないかもしれないことを意味します。データ間の関係をより詳細に分析し、電話をかけます。