マルチサイトシステムとは、同じバージョンの複数のペインを持つシステムを指します。この例として、Gamespotがあります。ここでは、uk.gamespot、us.gamespotなどにいるかどうかに応じて、さまざまなリリース日やさまざまなゲームが表示されます。
ここでは、サイトの選択はこの問題ではありません。問題は、開発のプロセスと容易さ、およびサイト固有のデータをどのように選択または入力するかです。また、さまざまなシステムコンポーネントがサイト固有である必要がない可能性もあり、まれに、すべてのサイトのすべてのデータが表示され、レポートおよび管理目的で選択可能である必要があります。
以下の手法が検討されており、それらが機能することはわかっていますが、それらの実装の面倒な性質に不満があります。
テーブルビュー-各テーブルのサイトごとに複数のビューを作成することで、サイトに固有のクエリ対象のデータを読み込むことができます。ただし、インラインSQLは正しいビューを動的に呼び出す必要があり、新しいサイトが作成された場合は、新しいビューのフルセットを作成する必要があります。
SQLの変更-SQL中間関数を作成することにより、SQLを変更して、サイトに固有のデータのみを選択するターゲット列へのwhere句と結合を変更できます。ただし、このようなデバイスを介してすべてのクエリを実行すると、将来的に深刻な問題が発生する可能性があり、クエリの柔軟性が制限される可能性があると考えています。
インラインサイト条項-これは実装が最も面倒で苛立たしいものですが、コーディング方法に標準を適用できれば、最も信頼性が高いことがわかります。これは潜在的に最も信頼性が高いですが、開発者にとって最も魅力的ではありません。これは、ほぼすべてのクエリに対してサイト句を作成することを意味します。
したがって、システムのより高いレベルでこのシステムを実装するための最良の手段を見つけるのではなく、基本レベルでサイト固有のデータ選択をかなり簡単に実装できる方法を見つけようとしています。
この質問が広すぎる場合はお知らせください。さらに絞り込みます。
最初の編集：
サイト全体のデータのタイプは、テーブルに関して同じです。ユーザーテーブルはすべてのサイトで共有され、各ユーザーは1つ、一部、またはすべてのサイトにのみアクセスできます。
Gamespotの例をもう少し詳しく見てみましょう。1人のユーザーには、UKバージョンを管理する責任が与えられます。
ゲームとそのレビューに関する情報は、グローバルに関連する情報であるため、すべてのサイトにアクセスできるレコードから取得されます。ただし、リリース日は、サイト固有の別のテーブルから取得されます。ゲームに関する情報は通常の方法で取得されますが、リリース日を取得するには、正しいサイトの正しいコードを取得するために少し余分なコードが必要です。
ユーザーに関しては、そのユーザーが現在管理しているサイトは、選択と挿入の対象となるサイトである必要があります。
ご想像のとおり、リリース日はコアテーブルではなく、各日付をそれぞれのゲームに直接マッピングすることはできません。
（Gamespotの動作についての知識があることを意味するものではありません。例は架空のものです）