問題タブ [entity-attribute-value]

EAV/CRデータベース モデルが悪いと言っても過言ではありません。そうは言っても、

質問:実行時に変更できる e コマース製品を記述する属性の「クラス」を処理するには、どのデータベース モデル、手法、またはパターンを使用する必要がありますか?

優れた電子商取引データベースでは、オプションのクラスを保存します (テレビの解像度のように、各テレビの解像度がありますが、次の製品はテレビではなく、「テレビの解像度」がない場合があります)。それらをどのように保存し、効率的に検索し、ユーザーが製品を説明する可変フィールドで製品タイプを設定できるようにしますか? 顧客が通常、コンソールの深さに基づいてテレビを検索することが検索エンジンによって判明した場合は、フィールドにコンソールの深さを追加し、実行時にテレビ製品タイプごとに 1 つの深さを追加できます。

優れた e コマース アプリには、一連の製品を表示し、「TV 解像度」をヘッダーとして表示できる「ドリルダウン」サイド メニューと、最も一般的なテレビ解像度のトップ 5 を表示する、優れた共通機能があります。見つかったセット。1 つをクリックすると、その解像度のテレビのみが表示され、サイド メニューで他のカテゴリを選択してさらにドリルダウンできます。これらのオプションは、実行時に追加される動的な製品属性になります。

さらなる議論：

簡単に言えば、次のセットアップを「学術的に」修正できるインターネットまたはモデルの説明にリンクはありますか? カテゴリ テーブルを提案してくれた Noel Kennedy に感謝しますが、それ以上の必要性があるかもしれません。以下では、重要性を強調するために別の方法で説明します。問題を解決するために視点の修正が必要な場合や、EAV/CR をさらに深く掘り下げる必要がある場合があります。

EAV/CR モデルに対する肯定的な反応が気に入っています。私の仲間の開発者は皆、Jeffrey Kemp が以下で触れたことを言っています。問題は：

• エンティティは毎週属性を追加および削除します
  (検索キーワードは将来の属性を決定します)
• 新しいエンティティが毎週到着し
  ます (製品は部品から組み立てられます)
• 古いエンティティは毎週消えます
  (アーカイブ済み、あまり人気がなく、季節限定)

顧客は、次の 2 つの理由で製品に属性を追加したいと考えています。

• 部門・キーワード検索・類似商品比較表
• チェックアウト前のコンシューマ製品構成

属性には、単なるキーワード検索ではなく、意味がなければなりません。「ホイップ クリームのフロスティング」があるすべてのケーキを比較したい場合は、ケーキをクリックし、誕生日のテーマをクリックし、ホイップ クリームのフロスティングをクリックしてから、ホイップ クリームのフロスティングがあることを知っている興味深いすべてのケーキをチェックします。これはケーキに固有のものではなく、単なる例です。

SQL Server を使用して、名前と値のペア テーブルを用意します。各行は基本的に、userid、contentid、sectionid、parameter、value です。そこで、ユーザー情報などテーブルに表示したいデータがあります。情報の各ビットはそれぞれの行にあります。それを DataSet に取得して Repeater で使用するにはどうすればよいでしょうか? どういうわけか行を1つにマージできますか? では、1 つの行で複数のパラメーター/値のペアを取得できますか?

以下のようなので...

ユーザー 32 の 2 つの行:

次のようにリピーターで 1 行に表示されます。

何か案は？そうそう、名前/値のペア形式になっている理由は、必要な標準に準拠するためです。

私は現在、サイトのアイデアのためにいくつかのものをいじっています-ユーザーがデータを保持する「テーブル」を作成し、このデータをクエリできるようにしたいと思っています（書くよりもオタクな方法ではありません） SQLクエリとうまくいけばExcelを使用するよりも簡単です）。

これまでの私の考えは、2つのテーブルを使用してデータベースでこれを表すことです。1つのテーブルがテーブルを表し、1つのテーブルがテーブルの列を表し、1つのテーブルがテーブルの各行を表し、最後に1つが値を表します。 。（PSEUDO SQL）に似たもの：

（ここでは、TableValuesテーブルに2つの主キーフィールドがあることに注意してください。これは「複合」主キーを表すことになっています。私の構文が正当なSQLではないという事実をあまり気にしないでください。これは、アイデアを示すためだけのものです）。

これを使って少しテストを行い、簡単なクエリ（簡単なフィルタリング、順序付けなど）を正常に実行できました。これを行う私の方法は、最初にTableRowsテーブルをクエリすることでした-フィルタリングのために、列が基準に一致しなかった行をフィルターで除外し、並べ替えのために、列の内容に基づいてRowIdを並べ替えました（指定された並べ替えで指定されたとおり）。希望する順序で行IDのリストが作成されます。これ以降は、必要なものを選択するだけで済みます。

これはすべて正常に機能しますが、これからは少し行き詰まります。どういうわけか、さまざまなデータ型を表現できるようにしたいと思います（これは私の主な問題です）。また、後で結合を行う方法を検討します。

このすべてを考えている間、私はこれを行うためのより良い方法があるかどうか疑問に思い始めます。もちろん、ここでのパフォーマンスが要因であることに注意してください。ただし、数十万行、おそらく仮想テーブルあたり約1000行の仮想テーブルをサポートする予定はありません。もちろん、システム全体で多くのこれらは。

これを実現するために、C＃でオンザフライで作成されたクエリを使用して、データベースにテーブルを実際に作成できます。同様に、SQLクエリのみを使用してクエリを実行できます。ただし、ユーザーがデータベースに対してクエリを「構築」できるようにすることは、これまで大ファンではありませんでした。このように-そしてそれは多くのバグが現れる道をたどるだろうように私には思えます-そして最悪の場合のシナリオはユーザーが何らかの方法でデータベースを殺すことを許してしまうでしょう。

また、私の問題は、C＃の観点から意味のある方法でこれに対処する方法になります。これまでのところ、私はLINQの使用に傾倒していて、必要な機能を適用する独自の拡張メソッド、つまりIQueryableを拡張するExtensionMethodsを作成していると思います。

ですから、私が本当に望んでいるのは、これを行う方法のアイデア、パフォーマンスを調整する方法のアイデア、テーブル内の個別のデータ型を処理する方法のアイデアです（もちろん、タイプをテーブル列に格納しますが、実際に値を格納して、フィルターや並べ替えなどを実行できるようにしますか？-tablevaluesテーブルに「TextValue」や「MoneyValue」などの列を追加するだけではありません）。そして最後になりましたが、ここでいくつかの良い議論ができれば幸いです。少なくとも、これはやや興味深いトピックだと思います。

ブログ アプリケーションのようなアプリケーションを作成する必要がある場合、データベース スキーマの作成は比較的簡単です。いくつかのテーブル、tblPosts、tblAttachments、tblCommets、tblBlaBla を作成する必要があります。

ユーザーが実行時にスキーマの一部を定義できるようにしたいアプリケーションがある場合はどうでしょうか。ユーザーがあらゆる種類のデータを記録できるアプリケーションを構築するとします。あるユーザーは自分の勤務時間 (startTime、endTime、プロジェクト ID、説明) を記録したいと考えており、次のユーザーは料理のレシピを収集したいと考えています。他のユーザーは、株価情報、赤ちゃんの週ごとの体重、毎月の食費、結果などを収集したいと考えています。好きなサッカーチームとか、考えられることならなんでも。

非常に異なる種類のデータをすべて保持するデータベースをどのように設計しますか? あらゆる種類のデータを保持できる汎用スキーマを作成しますか? ユーザー データ スキーマを反映した新しいテーブルを作成しますか? それとも、それを行うための別の優れたアイデアがありますか?

重要な場合: SQL Server / Entity Framework を使用する必要があります

Magento API 経由で製品をアップロードしていますが、フロントエンドに表示されません。バックエンドに入り、それらを開き、何も変更せず、製品を保存すると、製品が表示されます。

理由はありますか？バックエンドに保存する行為は、DBにいくつかの余分なフラグを保存していると思いますが、何がわかりません。

@スティーブ・マドセン。ここにコードがあります。バックエンド インターフェイスがそれを促し、製品を開いたので、重要なものが欠けているとは思いません。

今後のスーパーヒーロー映画のリリースに関するインサイダー情報を収集していて、メインの映画テーブルが次のようになっているとします。

表1

これは一般的に非常にうまく機能し、非常に簡単なクエリと行間の比較を可能にするはずです。

ただし、各データファクトのソースと、ファクトを発見したジャーナリストの名前を追跡する必要があります。これは、次のようなEAVテーブルのようなものを示唆しているようです。

表2

これにより、必要なメタデータを簡単にキャプチャできますが、クエリが難しくなります。1つの映画のすべての基本データを取得するには、もう少し時間がかかります。より具体的には、ここで4つの行を処理して、グリーンランタンに関する4つの重要な情報を取得する必要がありますが、表1では、1つの適切にカプセル化された行です。

だから私の質問は、私が今説明した複雑さを考慮して、そして私は一般的にEAVテーブルが避けられるべきであることを知っているので、EAVはまだ最良の解決策ですか？このデータを表現する唯一の合理的な方法のようです。私が見る他の唯一の選択肢は、次のようなメタデータのみを格納する別のテーブルと組み合わせてテーブル1を使用することです。

表3

ただし、これは非常に危険です。テーブル1の列名を「Villain」から「PrimaryVillain」に変更しても、テーブル3の行は単に「Villain」と表示されるため、残念ながら関連データが分離されます。これは、「属性」列がテーブル1の列の列挙として機能する別のテーブルにリンクされている場合に役立ちます。もちろん、DBAは、この列挙テーブルをテーブル1の実際の列と一致するように維持する責任があります。列挙テーブルを手動で作成する代わりに、テーブル1の列の名前を格納するSQL Serverのシステムビューを使用することで、これをさらに改善できる可能性があります。システムビュー。

何を指示してるんですか？EAVは行く唯一の方法ですか？

そして、それが1つのメタデータ列（「ジャーナリスト」なしの「ソース」のみ）であった場合はどうなりますか？それでもEAVルートに進む必要がありますか？「Director」、「Director_Source」、「Leading Male」、「Leading Male_Source」などの列を作成できますが、すぐに醜くなります。私が考えていないより良い解決策はありますか？

不明な点がありましたらコメントしてください。必要に応じて追加します。そうそう、私が使用した映画データは作成されています:)

編集：私の主な質問を簡潔に言い換えると、テーブル1のシンプルさと真のRDBMS設計が必要です。これは、安全でアクセス可能な方法で属性のメタデータを保存しながら、映画のエントリを実際によく説明しています。これは可能ですか？それともEAVが唯一の方法ですか？

編集2：さらにいくつかのWeb調査を行った後、メタデータを列に格納したいという願望を中心としたEAVに関する議論はまだ見つかりません。EAVを実装する主な理由は、ほとんどの場合、動的で予測不可能な列ですが、私の例ではそうではありません。私の例では、常に同じ4つの列があります。ディレクター、主要な男性、主要な女性、悪役です。ただし、各行の各列に関する特定の事実（ソースおよびジャーナリスト）を保存したいと思います。EAVはこれを容易にしますが、私はそれに頼ることを避けたいと思います。

アップデート

列の名前を「Movie」から「Name」に変更し、テーブル全体を「Movie」と呼ぶことを除いて、表2の設計を使用して、表1に戻るためのSQLServer2008のピボット操作を次に示します。

私はこの質問を書き直すと思いました（同じ繰り返し）。オリジナルは、EAV/CRデータベースの周りにリポジトリパターンをラップする方法でした。私は別のアプローチを試みています。

質問：「ファクトリ」デザインパターンの方法でデータリポジトリをどのようにコーディングできますか？ エンティティの数は固定されていますが、これらのエンティティの属性はかなり顧客固有です。彼らはすべて類似した製品を宣伝していますが、各顧客はビジネスモデルに基づいて異なる情報を提供しています。たとえば、廃棄物のスラブの割合を気にする人もいれば、販売されたポンドの量を気にする人もいます。別の顧客を見つけるたびに、一連のフィールドを追加し、一連のフィールドを削除してから、各ソリューションを最新の一般的なリリースに最新の状態に保つために何時間も費やします。

リポジトリクラスをファクトリパターンに配置できると思ったので、顧客のタイプがわかれば、どのフィールドを使用するかがわかります。実用的？もっといい方法？Webフォームは、レイアウト上のフィールドを反映するように変更されたユーザーコントロールを使用します。現在、レイアウトで見つかったフィールドを製品テーブルで見つかったフィールドに「結合」してから、CRUD共通フィールドを結合しています。

前の質問の内容：

同じエンティティに対して異なるクラスを許可するEAV/CRデータモデルがあります。これは、顧客が大きく異なる製品を持っている製品を追跡します。顧客は、製品の「クラス」を定義し、フィールドをロードしてから、データを入力できます。例えば、

Product.Text_Fields.Name
Product.Text_Fields.VitaminEContent

これにリポジトリパターンをラップする方法について何か提案はありますか？

3つのテーブルEAVがあります。Productテーブル、valueテーブル、およびフィールド名とデータタイプを一覧表示するメタテーブルです（Product.PriceやProduct.Priceメタデータなどの他のテーブルがあるため、データタイプを一覧表示します。 Product.Photoのような他の人と一緒に。）顧客は、競合他社のパーセントオフの差やその場での計算など、あらゆる種類の価格を追跡します。

現在、C＃でLinqtoSQLを使用しています。

編集：

以下の「動的クエリ」Linqが好きです。私たちのDBの背後にある考え方は、ロッカールームのロッカーストレージのようなものです。各アスリート（またはお客様）は、ご希望の方法でロッカーを整理し、保管を行っております。彼らが必要なことをすることができる限り、私たちはロッカーに何が入っているかを気にしません。

非常に興味深い...リポジトリに渡されるオブジェクトは動的である可能性がありますか？これは、ファクトリパターンのように、ほとんど意味があります。お客様が独自のクラス定義をテキストファイルに入れて、それらを継承してDBに保存することは可能でしょうか？

私は最近、EAVデータベース構造に大きく依存するシステムを継承しましたが、パフォーマンスの観点からは本当に苦労しています。

私がやりたいのは、nhibernateまたは別の適切なORM製品を使用して、行をプロパティにマップできるように、これらのEAVテーブルをエンティティにマップすることです。次に、データベースをリファクタリングして、リレーショナルにすることができます。これが可能かどうか誰かが知っていますか？例もいただければ幸いです。:)

構造の感触を与えるために、次のようになります。

Entity（EntityId）EntityVarchar（EntityId、VarcharValue）EntityFloat（EntityId、VarcharValue）

等々。Customerエンティティがある場合は、Customer.Varchar ["Name"]ではなく、Customer.Nameと言って名前を取得します。

私たちのシステムではEAVモデルを使用する必要はなく、データ構造の実行時の変更は許可されていないことに注意してください。とにかくそれは悪い習慣だと思います。