私は、フィードバック/調査環境のようなものでユーザーに表示されるフィールドをクライアントが定義できるようにするアプリケーションに取り組んでいます。たとえば、ピッツェリアにはお気に入りのトッピングを求めるフィールドがあり、バーにはお気に入りのビールのブランドがあるかもしれません。
これらのフィールドは特定の顧客に依存しており、おそらく複製されることはないため、システムは顧客がこれらのフィールドを作成および変更できるようにする必要があります。似たようなお客様の分野に基づいて、お客様に提案を提示する方法があれば理想的です。たとえば、2 番目のピッツェリアのサインアップがある場合、管理ページでフィールドを定義すると、同様のビジネスが次の質問をすることを選択し、「サンプル」値のリストを提示することが示される場合があります。
Entity-Attribute-Value (EAV)これは、このテーブルのモデルの適切な候補でしょうか? 従来のリレーショナル モデルは、「user1」などと呼ばれる多くのフィールドを含むため機能しません。もちろん、これは非常に扱いにくいものです。
いいえ、あなたが説明するシステムはEAVを必要としませんが、以下に示すものにはEAVモデルと共通の要素がいくつかあるように見えるかもしれません:
CLIENT (クライアント ID、クライアント名)
SURVEY (surveyId、clientId)
RESPONDENT (respondentId、surveyId、respondentName、respondentEmail)
QUESTION (questionId、surveyId、questionText) 例: 「お気に入りのトッピング」
OPTION (questionId, responseText) 例: 「アンチョビ」、「ペパロニ」
RESPONSE (questionId、respondentId、responseText)
CLIENT は多くの SURVEY を作成でき、それぞれに多くの QUESTION を含めることができ、いくつかは提案された OPTION を含みます。RESPONDENT は SURVEY に回答し、その回答はそれぞれ RESPONSE として記録されます。RESPONSE.responseText は、オプションを選択したか、独自の応答を入力したかによって、特定の OPTION.responseText と一致する場合と一致しない場合があります。
これは単なる例です。このモデルには、特定の要件に合わせて作成する必要がある多くのバリエーションがあります。