1

さまざまなクライアントから配布された顧客調査を分析する MySQL 駆動の Web サイトを構築しています。一般に、これらの調査はかなり一貫して構成されており、クライアントのデータのほとんどは同じ正規化されたデータベース構造に縮小できます。

しかし、すべてのクライアントは必然的に、他のすべてのクライアントには関係のない非常に具体的な人口統計学的質問を顧客に含めることになります. たとえば、すべてのクライアントは顧客満足度について質問しますが、自動車のクライアントだけが、顧客がマニュアル トランスミッションの運転方法を知っているかどうかを尋ねます。

これまで、respondentsすべての一般的な人口統計情報のテーブルに列を追加してきましたが、多くdefault nullの が混在しています。しかし、クライアントを追加すると、膨大な数の列が作成されることは明らかです。ほとんど常に null です。

これを一貫して行う方法はありますか？respondentsインポート スクリプトはテーブル用に既に作成されているため、できるだけ多くの標準化されたデータをテーブルに保持したいと思います。私の考えの 1 つはrespondent_supplemental_demographic_info、response_id、demographic_field、demographic_value の列を持つテーブルを作成することです (手動送信の例は、'ID999'、'can_drive_manual_indicator'、true になる可能性があります)。これは無限の数の demographic_fields を保持できますが、処理とプログラミングの両方の観点から作業するのは非常に困難です。何か案は？

4

2 に答える 2

0

この問題に対する解決策は、エンティティ属性値 (EAV) と呼ばれます。これにより、列が「ピボット解除」されるため、それらはテーブル内の行になり、それらを 1 つのビューに結び付けます。

EAV 構造は、扱い方を学ぶのが少し難しいです。単一のビューを取得するには、さらに多くの結合または集計が必要です。また、値の型が難しくなります。通常、値列は 1 つなので、すべてが文字列として格納されます。もちろん、異なるタイプのタイプ列を持つこともできます。

エンティティIDが各行で繰り返されるため、それらはより多くのスペースも占有します(response_idあなたの場合はそうだと思います)。

すべての状況で考えられるわけではありませんが、あなたが説明するような状況では適切です。無期限に属性を追加しています。1 つのテーブルで許可されている列の最大数 (データベースによって異なりますが、通常は 1,000 から 4,000 の間) をすぐに超えてしまいます。また、各列の各値を個別に追跡することもできます。たとえば、それらが異なる時間に追加された場合、入力時のタイム スタンプを保持できます。

もう 1 つの方法は、クライアントごとに個別のテーブルを維持し、他のプロセスを使用してデータを結合して共通のデータ構造にすることです。

于 2013-06-28T14:23:37.037 に答える
0

キーと値のペア (フィールド ID、フィールド値) を持つテーブルは非効率的であるため、当てはまらないでください。

あなたの場合、顧客ごとにテーブルを作成します。そして、これらのテーブルを記述するメタデータ テーブル (別の DB 内)。これらのメタデータを使用して、SQL などを生成できます。null列が多いことも間違いなく優れています。または、スクリプトをコピーして改造したもの。これには、アプリケーションがメタデータを使用して SQL を生成し、データを収集し (顧客固有のセマンティック知識なしで)、レポートを生成する、少しのプログラミングが必要です。

于 2013-06-28T14:22:49.657 に答える