1

EAV経由ではなく、カスタムユーザーフィールドの例/チュートリアルを探す

EAVは、パフォーマンスなどのさまざまな理由で問題になります

  • それぞれ100000を超えるレコードを持つ多くの基本エンティティ/テーブルがあります
  • おそらく12以上の属性があります
  • レコードは、フラットなUIグリッドに表示されます。カスタムフィールドは、パフォーマンスを維持しながらフラット化することが問題になります

すべてのカスタムフィールドが次のような一致するテーブルに入るDDLを介してこれを有効にすることを検討します

<tablename>_custom_<userid>

そして、すべてのユーザー属性は、メタデータテーブルに格納されているすべてのメタデータとそれぞれの列にマップされます

クエリが単純な場合、検索はより簡単になります

select  * 
from <tablename> A, tableName_custom_userid B 
where B.KeyField = A.KeyField --( perhaps using outer join, haven't gone that far yet )

私が知っておく必要がある道の先に何か落とし穴があるかどうか疑問に思いますか？

もちろん、サンプル/ポインターは、取り組みを開始するのに役立ちます

特に、SQL ServerCompact4でのDDLの使用に関するアドバイスをいただければ幸いです。

4

2 に答える 2

1

私が見たテクニックの 1 つは、一種の「ハードコードされた」EAV パターンを使用することです。電話を切らないで！あなたが話していたデータセットのサイズでうまく機能し、実際には EAV を使用しませんでした - それは EAV 風でした。

アイデアは、これらのカスタム属性をその中に格納する一連のテーブルを用意し、それらにいくつかのトリガー (後述) を設定することです。カスタム属性のテーブルセットには、属性に関するメタデータが格納されます (どのテーブルと組み合わせるか、データ型、制約など)。あなたはこれで非常に空想を得ることができますが、私はその必要がありませんでした.

メタテーブルのトリガーは、DB 内のファースト クラス オブジェクトにベース + エクステンションをロールアップするビューを再生成するためにあります。したがって、テーブル person + employee 拡張テーブルの代わりに、両方を含む employee ビューがあります。カスタム属性テーブルに新しい値をドロップすると、トリガーはビューを再ロールし、新しいものを含めます。極端にやりたい場合は、トリガーにストアド プロシージャを書き換えさせることもできます。中間層のコードがどのように構造化されているかによっては、一部のコードを再コーディングする必要がありますが、データを読み取るルールを適用する場合は、いずれにせよこれが当てはまります。

テストでは、あなたが話しているレコードの数が比較的少ない場合、パフォーマンスはやや遅くなりましたが、ほぼ同じ劣化パターンに従いました (レコード数の 2 倍、〜 2 倍の速度)。

-- 編集 --

私が見た方法では、最初のクラスのオブジェクトを表すテーブルがありました。つまり、「人」の行と「従業員」の行などです。これを FCO と呼びます。次に、FCO を表すテーブルを格納するセカンダリ テーブルを作成しました。これを Srcs と呼びます。 person の場合、1 つの行があり、それが person テーブルです。Employee の場合、person テーブルと Employee 拡張の 2 つの行があります。Attribs と呼ばれる 3 番目のテーブルがあり、FCO を構成するテーブルの列を格納します。簡単にするために、Employee には ID、Name、Address があり、Employee には Hire Date と Department があり、明らかに PersonID は Person テーブルを参照しているとします。したがって、FCO テーブル (person と employee) に 2 行、Src テーブルに 3 行、Attribs に 8 行。

このビュー (vw_Employee と呼びます) は、2 つのテーブルから PersonID、Name、Address、Hire Date、Department を選択します。これは、OnMetadataChange と呼ばれる SQL ストアド プロシージャによって構築されます。

この SP は (トリガーまたはバッチ プロセスによって) 起動され、その目的は CREATE VIEW ステートメントを生成することです。すべてのファースト クラス オブジェクトを反復処理し、ビューを構成するテーブルのフィールドを収集し、それに基づいて CREATE ステートメントを発行します。そのため、OnMetadataChange はビューごとに DROP と CREATE を生成し、FCO テーブルのエントリごとに 1 回実行される動的 SQL ステートメントを生成します。トリガーでこれを行うことが望ましいですが、必須ではありません。FCO 定義があまり頻繁に変更されないことを願っています。変更された場合は、おそらくコード リリースもあるでしょう。その時点で OnMetadataChange SP を実行できます。

最終結果は 2 層データベースです。ビューは、アプリケーションにとって意味のある First Class Object レイヤーを構成します。アプリケーションはビューのみを使用します。テーブルは、アプリケーションが気にする必要のない「物理」レイヤーを構成します。メタテーブルは基本的に、FCO レイヤーと物理レイヤーの間のマッピングです。セットアップには時間がかかりますが、非常に効果的であり、EAV の多くの利点を提供すると同時に、3nf テーブルの具体的な利点 (インデックス可能性など) を提供します。

必要に応じて、サンプル SQL を公開できます。

于 2012-04-24T18:22:03.633 に答える
0

あなたが抱えている問題の一部は、スキーマのないデータを SQL データベースに格納しようとしていることですが、これはその強みではありません。あなたの人生をはるかに楽にする3つのアプローチがあります：

1) シリアル化されたカスタム フィールドを格納する列を用意します。どのような形式でも便利です。たとえば、この列には xml を格納できます。利点は、SQL Server Compact を使用できることと、レコードを簡単に取り戻せることです。欠点は、更新を行うために常に xml blob 全体をプル/プッシュする必要があり、カスタム フィールドに対してクエリを実行することが困難または不可能であることです。

2) SQL Server Express にアップグレードし、XML 列を使用します。これは最初の提案とほぼ同じですが、サーバー対応バージョンの SQL Server には XML データがネイティブにサポートされている点が異なります。これらの列にはインデックスを追加でき、データ内のフィールドをクエリで使用できます。

3) MongoDB や CouchDB などのスキーマのないデータベースを使用します。これらのデータベースはすべてスキーマレス データの保存に関するものであるため、カスタム フィールドは他のフィールドと何ら変わりはありません。そのため、カスタム フィールドにインデックスを付けてクエリを実行できます。利点は、カスタム データの操作が非常に簡単であることです。欠点は、モデル内に収まるようにデータを格納する方法を再考する必要があることです。

カスタム フィールドに基づいてクエリを実行する必要がない場合、またはビジネス ロジック内でカスタム フィールドをクエリできる場合は、最初のオプションが適しています。それ以外の場合は、コンパクトよりも多くの機能を備えたものに向かって誤ります. コストが決定要因である場合、SQL Server Express と MongoDB はどちらも無料です。

于 2012-04-27T21:26:02.250 に答える