2

心配ない！実際よりも複雑に見えます！ただ飲み物に取り掛かってください！

TLDRバージョン：他のエンティティと関係のあるエンティティを効率的にクエリおよび更新するにはどうすればよいですか？

これが私を困惑させている2つのテーブルを持つ興味深いデータモデリングシナリオです：

Entities { ID, Name, ScalarValue }

ComponentEntities { AggregateEntityID, ComponentEntityID, quantity }

AggregateEntityIDおよびはテーブルComponentEntityIDへの外部キーです。Entities

すでに血なまぐさい例をください

Drinks { ID, Name, Alcohol% }

DrinkIngredients { CocktailID, IngredientID, amount }

Drinks { 1, "Vodka", 40% }
Drinks { 2, "Tomato juice", 0% }
Drinks { 3, "Tabasco", 0% }
Drinks { 4, "Bloody mary", - }

DrinkIngredients { 4, 1, 0.2 } // Bloody mary has 0.2*Vodka
DrinkIngredients { 4, 2, 0.7 } // Bloody mary has 0.7*Tomato juice
DrinkIngredients { 4, 3, 0.1 } // Bloody mary has 0.1*Tabasco

ブラッディマリーのアルコール含有量を取得したい場合は、SELECT * FROM DrinkIngredients WHERE CocktailID == 4。

かなり標準的です。そこには何も奇妙なことはありません。リサはそれに情熱を加えることによってそれを少し甘くするのが好きです：

Drinks { 6, "Passion", 13% }
Drinks { 7, "Bloody Mary Pink", - }

DrinkIngredients { 7, 4, 0.8 }  // Bloody Mary Pink has 0.8*Bloody Mary
DrinkIngredients { 7, 6, 0.2 }  // Bloody Mary Pink has 0.2*Passion

リサのお母さんは長い間これらを味わってきたので、彼女は2つの間の究極のブレンドを見つけたと信じています。

Drinks { 8, "Bloody Milf", - }
DrinkIngredients { 8, 4, 0.45 } // Bloody Milf has 0.45*Bloody Mary
DrinkIngredients { 8, 7, 0.55 } // Bloody Milf has 0.55*Bloody Mary Pink

これらのいくつかをさらに追加すると、レベルで構成され、深い関係再帰が発生します。唯一の制限は、エンティティがそれ自体で構成されることはできないということです。

これは、有向非巡回グラフを形成しているようです。

RDBMS：データを「キャッシュ」する1つの方法は、関連するデータを計算し、それをエンティティ自体（またはおそらく別のテーブル）に格納することです。上記の例では、ブラッディマリーのアルコール含有量は、作成されてアルコール％フィールドに保存されたときに1回計算されます。この場合、更新された飲み物で構成されるすべての飲み物（および依存関係の階層全体）を更新する必要があるため、更新にはコストがかかります。

質問

RDBMS：葉の飲み物に到達するまで「親」の飲み物を取得するよりも、葉の値（他の飲み物で構成されていない飲み物）に到達するためのより良い方法はありますか？

RDBMSとNoSQLの両方で、これに問題があります。いずれにせよ。

結論：これは実用的で実行可能ですか？

私が必要としているのは反発です

代替テキスト

4

2 に答える 2

3

「RDBMS：葉の飲み物に到達するまで「親」の飲み物を取得するよりも、葉の値（他の飲み物で構成されていない飲み物）に到達するためのより良い方法はありますか？」

これを理解しないでください。他のもので構成されていない飲み物は、再帰とは何の関係もありません。それは単純なEXCEPTまたはWHERENOTEXISTESです。

そして、「リーフ値に到達する」（親が与えられた場合）は、モデル化に使用されるデータ構造（リレーショナルまたは階層）に関係なく、必然的にツリーをトラバースする必要がありますね。

RDBMSとNoSQLの両方で、これに問題があります。いずれにせよ。

RDBMSはこれに関して実際には問題がありません。この問題は、数十年前（80年代頃）にすでに特定されており、推移閉包演算とその一般化されたバージョンで関係代数を修正することで対処されました。SQLは再帰クエリを通じてこれをサポートし、フランクが言ったように、少なくともすべての大物はすべて、何らかの方法で再帰クエリをサポートします。

結論：これは実用的で実行可能ですか？」

再帰クエリを作成することは、これまでに行ったことがない場合、必ずしも簡単ではありません。それはそれを「非実用的」にしますか？わかりません。

于 2010-08-19T10:02:13.863 に答える
0

多くのRDMSは再帰クエリをサポートしています。たとえば、http： //msdn.microsoft.com/en-us/library/ms186243.aspxを参照してください。

于 2010-08-18T21:28:47.743 に答える