0

と呼ばれる隣接リストテーブルがあります（これには、再帰を容易にするためにマップされattributeたクロージャテーブルもあります）。attribute_closure

テーブル内の各エントリは 4 つの階層型の 1 つであり、各型は親型のエントリattributeを継承およびオーバーライドできます。考えられる 4 つのタイプは、階層によって、category、product_line、product、modelです。したがってcategory、定義された属性のツリーがあり、これは継承され、product_lineいつでもオーバーライドできます。productmodel

これは既存のアプリケーションの既存の構造であるため、再構築の提案は使用できません:-)

したがって、隣接リストattributeには次の列がid, parent_id, overrides_idありますoverrides_id: が設定されている場合、オーバーライドされた属性の の値と常に一致します。attribute.idparent_idoverrides_idparent_idparent_id

階層タイプごとに、タイプを属性にマッピングするサポート テーブルがありますcategory_id, attribute_id。

すべてのオーバーライドを考慮して、完全な属性ツリーを取得できる必要があります。

データの例 (この特定の例は製品レベルに限定されていますが、アイデアは理解できます)。必要に応じて、独自のサンプル データでさらに肉付けしてください。

attribute

+-------+-----------+--------------+
|   id  | parent_id | overrides_id |
+-------+-----------+--------------+
|  6036 |      5931 |         NULL |
|  6069 |      5931 |         6036 |
| 30955 |      5931 |         6069 |
+-------+-----------+--------------+

category_attribute

+-------------+--------------+
| category_id | attribute_id |
+-------------+--------------+
|           2 |         6036 |
+-------------+--------------+

product_line_attribute

+-----------------+--------------+
| product_line_id | attribute_id |
+-----------------+--------------+
|              16 |         6069 |
+-----------------+--------------+

product_attribute

+------------+--------------+
| product_id | attribute_id |
+------------+--------------+
|         69 |        30955 |
+------------+--------------+

上記の属性を含むツリーを30955照会すると、属性 ID のみが返されるはずです。表示されている他の 2 つの属性は 30955 までに廃止されるはずです。

前述のように、 、 、 をマップする典型的なクロージャ テーブルもancestorありdescendantますlevel。クロージャーを使用してオーバーライドが有効になったツリーを返す結果を含めることができる場合は、追加のブラウニー ポイント。:-)

4

1 に答える 1

0

私が最終的に行った解決策は、オーバーライドの階層を表す2番目のクロージャーテーブルを作成することでした（parent_idに基づいてクロージャーを作成するのと似ていますが、代わりにoverrides_idを使用します）。これにより、クエリを実行して、特定の属性のオーバーライドの階層全体を見つけることができます。

私はそれらすべてを終わらせるためのクエリを見つけることを望んでいましたが、2番目のクロージャーテーブルを使用する方が簡単で、パフォーマンスなどが優れていました。

于 2013-02-08T23:59:59.187 に答える