問題タブ [entity-attribute-value]

これは、私が何年にもわたって複数の場所で見たシナリオです。他の誰かが私よりも優れたソリューションに出くわしたかどうか疑問に思っています...

私の会社は比較的少数の製品を販売していますが、販売する製品は高度に専門化されています (つまり、特定の製品を選択するには、その製品に関するかなりの数の詳細を提供する必要があります)。問題は、特定の製品を選択するために必要な詳細の量は比較的一定ですが、必要な詳細の種類は製品によって大きく異なることです。例えば：

製品 X には、(仮説的に) 次のような識別特性がある可能性があります。

• '色'、
• '素材'
• 「平均故障時間」

ただし、製品 Y には特性がある可能性があります

• '厚さ',
• '直径'
• '電源'

製品 X と製品 Y の両方を利用する注文システムを作成する際の問題 (とにかくそのうちの 1 つ) は、ある時点で注文明細が「販売」しているものを参照する必要があることです。製品 X と製品 Y は 2 つの異なるテーブルで定義されているため、幅広いテーブル スキームを使用した製品の非正規化はオプションではありません (製品定義は非常に深い)。注文入力、編集、レポート作成が実用的です。

過去に試したこと

• 製品 X と製品 Y に共通の列を持つ「製品」という名前の親テーブルを作成し、次に「製品」を OrderLine テーブルの参照として使用し、製品 X のテーブル間のプライマリ サイドとして「製品」との FK リレーションシップを作成します。これは基本的に、'Product' テーブルを OrderLine とすべての異なる製品テーブル (例: Products X と Y) の両方の親として配置します。注文入力には問題なく機能しますが、「製品」レコードは、「製品」をより詳細な子である製品 X または製品に結合する方法を決定するために、製品の種類を追跡する必要があるため、注文のレポートまたは編集で問題が発生します。 Y.利点: キー関係が保持されます。 短所: レポート、注文明細/製品レベルでの編集。
• 注文明細レベルで「製品タイプ」列と「製品キー」列を作成し、いくつかの CASE ロジックまたはビューを使用して、明細が参照するカスタマイズされた製品を決定します。これは項目 (1) に似ていますが、共通の「製品」テーブルはありません。注文明細行とその製品定義の間の外部キーが完全になくなるため、これはより「迅速かつ汚い」ソリューションだと思います。利点: 迅速な解決。 短所: (1) と同じですが、RI が失われます。
• 共通のヘッダー テーブルを作成し、カスタマイズされた属性 (OrderLine [n] <- [1] Product [1] <- [n] ProductAttribute) のキーと値のペアを使用して、製品定義を均質化します。 利点: キー関係が保持されます。製品の定義に曖昧さはありません。 短所: レポート (属性を含む製品のリストの取得など)、属性値のデータ入力、パフォーマンス (製品属性の取得、製品属性の挿入または更新など)

他の誰かが別の戦略を試して成功した場合は、ぜひ聞いてみたい.

ありがとうございました。

私が参加しているいくつかのWebアプリケーションプロジェクトでは、クライアントが独自のフォームを作成できるように要求しています。フォーム定義をどのように保存するか、そしてユーザーが入力した値をそれらのカスタムフォームにどのように保存するかという問題が発生します。

私はそれが2つの方法で行われるのを見てきました：

1. クライアントがフィールドの数と、それらのフィールドに関連付けられているラベルのみを定義すると仮定します。4つのテーブルを含むソリューションにたどり着くことができます。 FormDefinition、、、、。FormFieldDefinition_ FormInstances_ FormFieldValuesクライアントはとに変更を加えFormDefinition、FormFieldDefinitionWebアプリはその情報を使用してHTML Webフォームをレンダリングします。このフォームで、Webサイト訪問者（エンドユーザー）がフォームを送信します。このフォームで、新しい行FormInstancesが作成され、値がに保存されます。FormFieldValuesテーブル。

   の行FormDefinitionはフォームを定義しますform definition ID = 2, form title = 'Car Registration Form'。の行は、のフォームFormFieldDefinitionのフィールドを定義します。行は、ユーザーが入力した各フォームのインスタンスです。そして、の行はユーザーによるエントリです。FormDefinitionfield definition ID = 7, field label = 'Car Model', field type = 'varchar(50)'FormInstancedefinition id = 2, date_entered = '2008-09-24'FormFieldValuesfield definition = 7, value = 'Tiburon'

   残念ながら、の値列はFormFieldValues、クライアントがWebフォームで指定できる最大サイズのchar型でなければならないことを意味します...フォーム定義が変更されると、古いデータの管理が困難になります。ただし、ユーザーエントリはクエリ可能です（別のピボット質問と同様に、フォームIDを指定してユーザーエントリを一覧表示する簡単なクエリを作成しました）。

2. 4つのテーブルを使用する代わりに、フォーム定義とユーザーのフォームエントリをXML（またはYAMLなど）にシリアル化し、それをテキストとして保存することもできます。利点は、フォームがデータベースで人間が読める形式であることです。欠点は、XMLの解析によりアプリケーションのオーバーヘッドが増加し、SQLの観点からデータベースのクエリがはるかに少なくなることです。

私の本当の質問は、このデータベースモデルは何と呼ばれているのかということです。（だから私はこの問題をグーグルで検索することができます。）しかし、私は答えを決めるでしょう：どちらがより良い実装ですか、それともそこにもっと良い（または同じくらい良い）実装がありますか？

非常に大規模な EAV またはオープン スキーマ スタイルのデータベースを SQL Server に実装した人はいますか? これにパフォーマンス上の問題があるかどうか、そしてそれらの障害をどのように克服できたのか疑問に思っています.

一部のカテゴリに属する​​製品がいくつかあります。

各カテゴリは異なるプロパティを持つことができます。

例えば、

• カテゴリの車には、 color、power などのプロパティがあります。
• カテゴリのペットには、 weight、ageなどのプロパティがあります 。

カテゴリの数は約 10 ～ 15 です。各カテゴリーの物件数は3～15物件。商品数は非常に多いです。

このアプリの主な要件は、非常に優れた検索です。カテゴリを選択し、このカテゴリの各プロパティの基準を入力します。

このシナリオのデータベースを設計する必要があります。(SQL サーバー 2005)

PHP/MySQL 用のエンティティ属性値フレームワークはありますか? 私は自分で書き始めていますが、すでに終わっているように感じます。助言がありますか？

[以前のタイトル：タグベースの組織方法論に関係構造を強制する方法はありますか？]

私にはいくつかのエンティティがあり、それらには一連の属性があります。一部の属性は、エンティティが持つことができる他の属性に影響を与えます。多くの属性はグループに編成され、エンティティは、特定のグループからの特定の数の属性、または場合によっては特定のグループからのある範囲の属性を持つように要求されることがあります。

データベースを使用して、要件、グループ化、除外など、この種のタグ間の関係をモデル化する方法はありますか、それともプログラムされた「ビジネスルール」でのみ可能ですか？理想的には、可能なタグとそれらの関係を簡単に構成できるようにし、それによって柔軟性を高めたいと思います。

私が検討した方法の1つは、タグと可能な関係を設定することです。そうすると、タグとタグが適用された関係のようなテーブルが得られますが、これはかなり脆弱なアプローチのようです。

それで、これはより厳密な方法で可能ですか？もしそうなら、私はそれについてどのように始めますか？

投稿されたフォーム データを分析するためのスター スキーマに取り組んでいます。フォーム データが投稿されるサイトは、実際にはフォームをホストするサイトの外部にあるため、フォーム内のデータのみが利用可能になります。非表示のフィールド、元のリファラー、セッション ID などの追加の有用な情報を含めるオプションを提供します。

正規表現を使用して特定のデータ型に一致させ、郵便番号などの特定の次元に引き出すことができます。

次元の恣意的な性質に対処するための解決策があります。それは素晴らしいものではありませんが、うまくいくでしょう。

私が抱えている問題は、ファクト テーブルに何が入るかわからないことです。集計できる適切な数値があるわけではありません。これらの基準を満たす「はい、フォーム投稿があります」という事実は別として。

私はこれに正しい方法でアプローチしているかどうか疑問に思っていますか？仕事に間違ったツールを使用していませんか? それとも、何かが足りないのですか？

サイモン。

詳細:

機能には 2 つの領域があり、2 つのタイムスタンプなどの条件に基づいてフォーム投稿をフィルタリングします。しかし、フィルタリングに関しては、ほとんど何でも手に入れることができます。選択したフォーム投稿は、エクスポート用の csv ファイルを生成するために使用されます。

もう 1 つの主な分野は分析です。広告費から顧客へのリードへの変換を研究することは、当然の出発点です。また、多少オープンエンドであり、フォームデータに依存します。

いくつかのフィールドを持つ SQL テーブルがあります

ID | 値 | タイプ

典型的なレコードは次のようになります:- 1000,10,[int]

2 番目の行は次のようになります。

1001、フー、[文字列]

3 番目の行は次のようになります。

1002,10/12/2008,[日時]

現時点では、このテーブルから選択するたびに、指定された型に値をキャストする必要があるため、これを確認するように依頼されました。これでデータベースの再設計を行うことができ、これを最適化するための最善の方法を考えています。(SQL 2000)。

データベースでこれらの関係をどのようにモデル化しますか?

PageElements を含むことができる Page エンティティがあります。

PageElement は、たとえば Article や Picture にすることができます。Article テーブルには、明らかに、Picture 以外のメンバー/列があります。記事には ie が含まれる場合があります。「Title」、「Lead」、「Body」列はすべて nvarchar 型ですが、Picture には「AltText」、「Path」、「Width」、「Height」などがあります。私はこれを拡張可能にしたいのですが、3 か月でどのような PageElements が必要になるかは誰にもわかりません。したがって、PageElementTypes テーブルが必要になると思います。

リレーションシップについては、次のようなテーブルはどうでしょうか。

Id を持つページ、およびその他の巨大なジャンボ。(作成日、表示可能、その他)

PageIdと PageElementId を持つ Pages_PageElements。

Id とPageElementTypeIdを持つ PageElements と、さらに巨大な (SortOrder、Visibility など)。

ID と名前を持つPageElementTypes (たとえば、"Article"、"Picture"、"AddressBlock")

ここで、すべての Articles、Pictures、AddressBlocks テーブルに PageElementId 列を作成して、作業を終了する必要がありますか? これは単純な 1 対 1 の関係であるため、これでうまくいくはずですが、どういうわけか何かを見落としている可能性があります。

ファローアップ：

個別の属性を使用した以下の推奨ソリューションでは、すべての属性を同じタイプとして保存する必要がありますか? 1 つの PageElement の属性が nvarchar(255) で、一部が nvarchar(1000) の場合、一部が整数の場合はどうなりますか?

EAV の方法を取得した場合、そこにあるすべての異なるデータ型の属性値を保持するために、大量のテーブルを作成する必要があります。

オブジェクト指向プログラミングのスーパークラスのように機能する DB (Postgres ベース) にテーブルがあります。テーブルに追加する列を決定する「タイプ」列があります (サブクラス プロパティ)。しかし、可能なすべての列 (可能なすべての型のすべてのプロパティ) をテーブルに含めたくありません。

そこで、「キー」列と「値」列 (つまり、「ファイル名」 = 「/ファイル」、または「値」 = 「5」) を含むテーブルを作成することにしました。スーパークラス テーブルで。また、使用可能な「キー」値を含む関連テーブルを 1 つ作成しました。

しかし、このようなアーキテクチャには問題があります。何でも含めることができるように、「値」列はデフォルトで文字列データ型でなければなりません。しかし、文字列との間の変換は良い決断ではないと思います。この制限を回避する最善の方法は何ですか?