2 つ以上のドメインと 1 つのデータベースがある場合、データベースを設計してデータを整理する方法を教えてください。e コマースを目的としたすべてのサイトと、各サイトで 1 つの商品を販売できます。だから私は2つのアイデアしかありません：
どちらのアイデアにも大きなマイナスがあります。何か案は？ありがとう。
これは、マルチテナント システムを構築する際の典型的な問題です。この件に関してはいくつかの異なる意見を聞いたことがありますが、それらは基本的に 2 つの陣営に分けられます。
site_id特定のテナントのデータを含むすべてのテーブルでテナント ID (この場合) を使用します。このアプローチの支持者は、データが属するテナントを簡単に識別できることを主な利点として挙げ、データのアーカイブ方法 (顧客ごとに異なるテーブルスペース) に影響を与えます。
テナント ID は、高レベルのテーブルでのみ使用してください。このアプローチの支持者は通常、よりクリーンなデータベース構造であるという利点を説明します。
私は、さまざまな顧客からの同じ種類のデータに対してさまざまな物理テーブルを作成するのが好きではありません。これには多くの好ましくない結果があります。
スキーマのどこかに、他のすべてのテーブルにリンクしている少数のテーブルがある可能性があります。データベース内のすべてのテーブルではなく、site_id を入れる必要があるのはこれらのテーブルです。
(非常に不自然な) 例として、スキーマに Customers テーブル、Invoices テーブル、および Invoice Line Items テーブルが含まれている場合、3 つのテーブルすべてに site_id は必要ありません。Customer のテーブルには site_id だけが必要です。
私の好みは、必要に応じてマッピング テーブルを作成することです。製品はサイト 1、サイト 2 などに存在できると考えてください。製品の詳細はサイト間で変わりません。商品の価格はそうかもしれません！その場合、Prices テーブルには SiteID と ProductID が必要になる場合があり、ProductID は異なるサイト間でエントリごとに複製される可能性があります。これはユーザーにも言えることですが、ユーザーはこれを「兄貴」と感じるかもしれません。したがって、これは顧客にとってはうまくいくかもしれませんが、通常、顧客はサイトごとに異なるアカウントを持っていることをお勧めします! 物理的に機能しても、論理的に機能するとは限らない場合があります。SiteID は、どこにでも無計画に配置するのではなく、必要な場所に配置してください。アプリケーションが必要とする場所以外の場所で、この SiteID が必要になる場合があることに注意してください... オフラインのクエリについても考えてください。SiteID でフィルタリングするために 5 つの結合を行わなければならないのは最悪です! インデックスを維持することは、フィルタを探し回るよりも優れています!
類似した名前の個別のテーブルによる水平分割に関しては、SQL Server 2005 以降を使用してください。データサイズを心配する必要がなくなるように、パーティショニング機能を備えています。
Wordpress と Drupal で使用されているアプローチの 1 つは、テーブルに名前のプレフィックスを付けることだと思います。
dom1_Customers
dom2_Customers
この方法では、テーブルが不釣り合いに大きくなることはなく、site_id の余分なインデックスを維持する必要もありません。とは言っても、コードはそれを補う必要があり、再計測が必要になる可能性があります (ストアド プロシージャは基本的に厄介なものではありません)。