5

今後のプロジェクトの 1 つでこの概念を使用することを検討しています。

詳細: MySQL での階層データの管理。

良い経験も悪い経験も、例を挙げて教えてください。

より広くするために、さらに情報を追加しています。

複数の親を持つことができる子項目があります (例: ユーザーは都市に属し、UserDefinedRegion というグループにも属することができます)。これは、隣接リストであろうとネストされたセットであろうと、典型的な階層モデルではサポートされていません。

明確にするために、ここにユースケースを貼り付けています。

背景: 現在、システムには、都道府県 -> 郡 -> 市区町村 -> ユーザーという固定の階層があります。

  1. Sales Manager はシステムにログインし、City または County と同じレベルの新しいグループを作成します。

  2. Sales Manager はシステムにログインし、州と郡または郡と市の間にある新しいグループを作成します。

  3. 営業マネージャーがグループを作成すると、翌日にはダッシュボードにまとめられた必要なすべてのレポートを表示できるようになります。

ご覧のとおり、2 番目のポイントは入れ子になったセットによって簡単に実現できますが、同じ子ノードに新しい親ノードを導入する最初のポイントはそうではありません。

これまでに、stackOverflow ユーザーによって次のソリューションが提案されました。

  1. ネットワーク データベースがサポートするネットワーク ノード構造。
  2. 有向非巡回グラフ。

私は間違いなく RDBMS ソリューションを探しています。実際の階層データ モデルで複数の親ノードに遭遇した人はあまりいないようです。

4

2 に答える 2

4

参照記事で指摘されているように、複数の親に対する要件は、ネストされたセットの基本的な性質にすぐに違反するため、最初から問題が発生していると思います。リレーショナル データベースを使用するので (そのコア機能を使用して) これまでに説明したすべてを処理します。その概念的なフレームワークで作業し、スキルを磨くだけで、必要なすべてが得られると思います。追加の抽象化を追加する必要はありません。 (少なくともこの場合は) 値を追加しないでください。

それでもそこに行きたいのなら、私はこれをネットワーク化されたノード構造と呼んでいます。ここに参照があります。

于 2009-04-19T20:36:15.543 に答える