この循環データ参照をより良く設計できますか？

Question

私は色に関するデータを持っています。 これらの色の中には、いくつかの色を組み合わせたものがあります。 これらの組み合わせのうちの1つは、理論的には別の組み合わされた色です。 色を組み合わせた場合、「子供」色についていくつかの属性を定義する必要があります。

私は現在、私のデータベースはそうのように定義されている：

COLOR 
!Id 
+MultiColorGroupId 

MULTICOLOR 
    !Id 
    +MultiColorGroupId 
    +ColorId 
    +Type 

これは私がかなり明確な方法で必要なすべての情報を含めることができます。 私は考えられる唯一のことは、色がchildColorとしてある循環参照を取得することです。 現在、データベースまたはアプリケーションのいずれかに挿入されているかどうかを確認することによって、これをキャッチする唯一の方法があります。円の参照は恣意的に深いことがあり、現在の構造は潜在的にかなり広い可能性があるので、私はより決定論的なデータ構造を好むでしょう。

これを定義するより良い方法はありますか？

Answer 1

深さが任意の場合は、データ構造の問題を解決できません。考慮すべきことの1つは、自己参照が実際にデータベースに格納されている場合に問題がある場合です。おそらく、データを無限に読み取らないようにするためには、コードを取得する必要があります。

私は食品レシピで同様の問題がありました。ヨーグルトを作るためにヨーグルトが必要です（一般的な例を選ぶ）ので、その成分を保存するのをサポートし、特定の成分が一度しか分解されないようにするためにロジックを検索に当てなければなりませんでした。

Answer 2

これらのテーブルに（SQL以外の）インターフェイスがある場合、使用可能な選択肢からすべての「不正な」オプションを簡単に除外できます。そうでなければ、挿入時および更新時にトリガまたはチェック制約を使用できます。

Answer 3

私はトリガには注意が必要ですが、コードでこれを行う必要があると思います。トリガのコストは、構造の複雑さによって線形の関係よりもずっと悪くなります。

コレクションのコードでは、解決するのは非常に簡単な問題です。

テーブル定義では、このシナリオを実際に定義することはできません。これは、格納する構造ではなく、データ自体のプロパティであるルールです。

データ構造については、同じ構造を思いついた。