さまざまな Web サイトからのユーザーに関する情報を格納するデータベースを設計しようとしています。基本的に、ユーザーが別の Web サイトにログインして同じような情報を 1 か所で取得する必要がないように、ユーザー情報を集約したものです。mint.com のようなものです。問題は、これらのさまざまな Web サイトのほとんどに、さまざまなデータのサブセットが含まれていることです。たとえば、あるサイトでは約 47 列を要求し、別のサイトでは約 13 列しか要求しないとします。ここでの論理的な考えは、各 Web サイトを独自のテーブルに分割することです。しかし、47 列の 1 つのテーブルは扱いにくいように見え、それを小さなテーブルに分割しようとすると、もっと正気ではないように見えました。私の友人は、Web サイトのフィールド間に類似点があれば、テーブルを 3 つだけ持つことができると提案しました。そのようです：
上記の例では、基本的に、Web サイト スキーマごとにテーブルを作成した場合に列名になるものをすべて取得し、その列名を「field_name」列にエントリとして配置します。各サイトでユーザー情報が変更されるのは 1 日に 1 回 (早朝) だけであるため、複合キーはその日に基づいて一意のままになります。ウェブサイトのすべての値をそれぞれ独自のテーブルの 1 つの行に表示するのではなく、基本的にすべてセグメント化してデータを取得するには、基本的にすべてが WHERE 句で実行される、少し長いクエリが必要になります。
これは、1 つの Web サイトの 13 個すべてを使用し、それを Web サイトの 47 列の 13 個と組み合わせることができ、34 個の列について心配するだけでよく、マッピング テーブルを使用してデータを適切なサイトにマップすることができるとしたら、本当に良いことです。それでも、私はデータを分析しましたが、これを行う方法はありません..各サイトは、結合するほど類似していないため、すべてのフィールドを使用する必要があります. これは、上記の例のデータ テーブルが毎日約 120 行を生成することを意味します。私はこのコンセプトが本当に気に入っています...私の要件のいずれかが変更された場合、コード内でフィールド名に別の値を追加するだけでスキーマを編集する必要はありません。これは、他の方法に対する唯一の主な利点のようです。
各 Web サイトを独自のテーブルに分割し、1 つのテーブルが 47 であるにもかかわらず、4 つのテーブルで 1 日に 4 行しか生成しないようにする方が理にかなっているでしょうか。