1

多くの人がそうであるように、私はProducts /Product Propertiesデータベース スキーマを探しています。ファセット検索には Ruby on Rails と (Thinking) Sphinx を使用しています。

要件：

  • 新しい製品タイプとそのオプションを追加しても、データベース スキーマを変更する必要はありません。
  • Sphinx を使用したファセット検索をサポートします。

私が遭遇した解決策：
（Bill Karwinの回答を参照）

オプション 1: 単一テーブルの継承

本当にオプションではありません。テーブルには、多くの列が含まれます。

オプション 2: クラス テーブルの継承

Ruby on Rails は、起動時にデータベース スキーマをキャッシュします。これは、新しいタイプの製品が導入されるたびに再起動することを意味します。十分なサイズの製品カタログがある場合、これは数百のテーブルを意味する可能性があります。

オプション 3: シリアル化された LOB

複雑なアプリケーション ロジックなしでファセット検索を実行できることは致命的です。

オプション 4: エンティティー属性値

テスト目的では、EAV は問題なく動作しました。ただし、オプションを追加すると (オプションによって価格や納期が増加する場合など)、すぐに混乱してメンテナンス地獄になる可能性があります。

どのオプションを使用する必要がありますか? 他にどのようなソリューションがありますか? 私が見落としていた特効薬（ハ）はありますか？

4

1 に答える 1

2

IMOは、クラステーブル継承とEAVの組み合わせであり、いくつかの重大な制限があります。これが最善のアプローチです。

EAVは薬のようなものです。少量で限られた状況では、EAVは有益な場合があります。多すぎるとあなたを殺します。スキーマの主要部分としてのEAVは失敗します。質問なし。ただし、適切な制限を適用すると、優れたデータベーススキーマの補足として役立つ場合があります。

EAVの主なルールは、を含むクエリを作成することはできない'[AttributeCol] = 'Attribute'ということです。つまり、レポートやフォームのどこにも、フィルタリング、並べ替え、範囲の制限、特定の属性の配置を行うことはできません。これは、レポートまたは画面上のリストに完全に吐き出すことができる単なるデータの袋です。実際、私は人々がこの機能をXml列として実装しているのを見てきました。

この制限を維持できる場合は、ユーザーがストレージ目的でのみ製品に属性のセットを追加できるようにする手段として、クラステーブル継承設計にEAV構造を追加できます。属性を使用して冗長なタスクのいずれかを実行したい瞬間、それはファーストクラスの列になる必要があります。

重要なのは執行です。EAV構造の使用に関してこの制限を合理的に実施できる、または他の開発者に実施させることができないと思われる場合は、それをスキップするのが理にかなっているかもしれません。ただし、この制限を適用できれば、ストレージと追跡の目的でのみ大量の属性を追加したいという人々の問題を解決できます。

于 2010-05-04T14:25:55.447 に答える