0

以前に同様の質問をしましたが、誰も答えなかったので、問題を再考し、同様の/別の質問をしました。

親/ルート (トップ) アプリから始まるプロセスがあります。ルート アプリは、子孫アプリも生成できる子アプリを生成します。これは、複数のレベルで継続できます。各レベルは、ノードまたはリーフのいずれかになります。ノードは子孫を持つことができます。リーフには、生成された子/子孫アプリはありません。

プロセスの開始時に、アプリはレベルの数を認識しています。プロセスも構造化されているため、各子アプリは完了時に、独自の ID と親 ID を使用して tbl を更新できます。

したがって、プロセス全体が実行されると、結果のデータは階層ツリーになります。

ツリー内の特定のアイテム/ノードを確認し、子孫アプリが完成しているかどうかを判断する方法を見つけようとしています。

私はmysqlでこれを達成しようとしています。私はストアドプロシージャ/サブセレクトに精通していません。これについて議論している多くのオンライン ペーパー/サイトを見てきましたが、私の問題を解決しているようには見えません。

この問題を明確にするために、mysql の第一人者を探しています。

ありがとう！

---------------------------------

The sample tree would look like:

spawn
3 levels
a - 3 copies of b
b - 3 copies of c


                     a(1)
                      |
---------------------------------------------------------------------
          |b(1)                   |b(2)                            |b(3)
-------------------         -------------------          --------------------  
|c(1)    |c(2)    |c(3)     c(1)    |c(2)   |c(3)        |c(1)    |c(2)    |c(3)  


so we have a total of 12 crawls/fetches

the levels
a
b
c

the (parent/child) levelRelationships
"",a
a,b
b,c

start level
a (parent/top)
end level
c (leaf)


operational process:

an app spawns either no child app, a single child app, or multiple child app(s)
an app that spawns children is a node
an app that spawns no children is a leaf
 there is no guarantee that an app at a given level, will stop operation 
 before an app at a lower level started by it's parent
each child app can set a tbl with a status when it completes 
 when each child app is complete, it generates a "level/complete" status
  which is stored in a levelStatusTBL

at the start of the root/top level process:
-the tree can have multiple/unknown levels
-each child app can spawn an unknown number of children


issue...
 how to algorithmically determine when all the descendants of a root/top level function have completed?
 how to algorithmically determine when all the descendants of a node have completed

私が検討しているサンプル tbls は次のとおりです。

CREATE TABLE `crawlNodeChildrenCountTBL` (
  `rootID` varchar(100) NOT NULL DEFAULT '',
  `uCrawlID` varchar(100) NOT NULL DEFAULT '',
  `childCount` int(5) NOT NULL DEFAULT 0,
  `ID` int(10) NOT NULL AUTO_INCREMENT,
  PRIMARY KEY (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE `EdgeNodeCheckTBL` (
  `CollegeID` varchar(100) NOT NULL DEFAULT '',
  `rootID` varchar(100) NOT NULL DEFAULT '',
  `parentLevel` varchar(100) NOT NULL DEFAULT '',
  `Level` varchar(100) NOT NULL DEFAULT '',
  `nodeType` int(5) NOT NULL DEFAULT 0,     
  `masterParseInputUUID` varchar(100) NOT NULL DEFAULT '',
  `parentSetupPreComboID` varchar(100) NOT NULL DEFAULT '',
  `SetupPreComboChildStatusID` varchar(100) NOT NULL DEFAULT '',
  `ID` int(10) NOT NULL AUTO_INCREMENT,
  UNIQUE KEY `ID` (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;


EdgeNodeCheckTBL.SetupPreComboChildStatusID is the baseID
EdgeNodeCheckTBL.parentSetupPreComboID is the parentID of SetupPreComboChildStatusID

this is used to implement the standard child/parent relationship tbl
4

1 に答える 1

0

これは実際にはデータアルゴリズムの問​​題です。基本的な問題は、リレーション データベースの子レコードに親 ID を格納するには、再帰クエリが必要になることです。ストアド プロシージャまたは別の言語でそれを行うことができる場合、これは有効なアプローチです。

ツリーをリレーショナル データベースに格納するより良い方法は、ネストされたセット モデルを使用することです。アイデアは、各ノードが Left Id と Right Id を持っているということです。これは、各ノードが pre-order トラバーサルを使用してアクセスされたときの単純なシーケンスです。Left Id は、ツリーを下って最上位ノードから離れたときに設定されます。ツリーを一番上のノードに向かって上ると、Right Id が設定されます。ツリーが変更されると、番号も更新する必要があります。

この構造がもたらす利点は、ツリーを調べたり更新したりするために再帰的なクエリが必要ないことです。また、ツリーへの変更を 1 か所に分離して、左右の ID を正しく更新できるようにすることもお勧めします。

ウィキペディアの記事に詳細があります。

于 2012-01-20T05:10:49.077 に答える