10
エンティティ属性値データベースと厳密なリレーショナルモデルのeコマース
EAV / CRデータベースモデルが悪いと言っても安全です。それは言った、 質問：実行時に変更できるeコマース製品を説明する属性の「クラス」を処理するには、どのデータベースモデル、手法、またはパターンを使用する必要がありますか？ 優れたeコマースデータベースでは、オプションのクラスを保存します（テレビの解像度には各テレビの解像度がありますが、次の製品はテレビではなく、「テレビの解像度」がない場合があります）。それらをどのように保存し、効率的に検索し、ユーザーが製品を説明する変数フィールドを使用して製品タイプをセットアップできるようにしますか？顧客が通常はコンソールの奥行きに基づいてテレビを検索することが検索エンジンで判明した場合は、コンソールの奥行きをフィールドに追加し、実行時にテレビ製品のタイプごとに1つの奥行きを追加できます。 優れたeコマースアプリには、一連の製品を表示した後、「ドリルダウン」サイドメニューに「TV解像度」をヘッダーとして表示できるという優れた共通機能があり、上位5つの最も一般的なTV解像度がセットが見つかりました。いずれかをクリックすると、その解像度のテレビのみが表示され、サイドメニューで他のカテゴリを選択してさらにドリルダウンできます。これらのオプションは、実行時に追加される動的な製品属性です。 さらなる議論： 要するに、インターネットやモデルの説明に、次の設定を「劇的に」修正する可能性のあるリンクはありますか？ カテゴリテーブルを提案してくれたNoel Kennedyに感謝しますが、必要性はそれよりも大きいかもしれません。以下に別の方法で説明し、重要性を強調します。問題を解決するために視点を修正する必要があるかもしれませんし、EAV / CRに深く入り込む必要があるかもしれません。 EAV / CRモデルに対する肯定的な反応が大好きです。私の仲間の開発者全員が、ジェフリーケンプが以下に触れた内容を述べています。問題は： エンティティは属性を毎週追加および削除します （検索キーワードは将来の属性を指示します） 新しいエンティティが毎週到着します （製品はパーツから組み立てられます） 古いエンティティは毎週消えます （アーカイブされ、人気が低く、季節的） 顧客は2つの理由で製品に属性を追加したいと考えています。 部門/キーワード検索/類似製品間の比較表 チェックアウト前の消費者向け製品構成 属性には、キーワード検索だけでなく、重要性がなければなりません。「ホイップクリームのフロスティング」があるすべてのケーキを比較したい場合は、ケーキをクリックし、誕生日のテーマをクリックし、ホイップクリームのフロスティングをクリックし、ホイップクリームのフロスティングがあることを知っている興味深いケーキをすべてチェックします。これはケーキに固有のものではなく、単なる例です。