tree - ノードの子孫が完全である場合にmysqlを使い分ける方法

Question

前にも同様の質問がありましたが、誰も答えなかったので、問題を再検討して同様の/異なる質問をしました。

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

処理の開始時に、アプリはレベルの数を知っています。プロセスは構造化されているので、各子アプリは完了時にtblを自身のIDとparentIDで更新することができます。

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

私はツリー内の特定のアイテム/ノードを見て、子孫アプリケーションが完成しているかどうかを判断する方法を理解しようとしています。

私はこれを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 

Answer 1

これは本当にデータ・アルゴリズムの問​​題です。基本的な問題は、リレーションデータベースの子レコードに親IDを格納すると再帰クエリが必要になることです。ストアドプロシージャまたは別の言語のどちらでも構いません。これは有効なアプローチです。

ツリーをリレーショナルデータベースに格納するより良い方法は、nested set modelを使用することです。アイデアは、各ノードが、プレディオーダートラバーサルを使用して各ノードが訪問されたときのシーケンスである、左IDおよび右IDを有することである。左側のIDは、ツリーの一番上のノードから降りるときに設定されます。右ノードに向かってツリーを上にするときに右IDが設定されます。また、ツリーが変更されたときに番号を更新する必要があります。

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

詳細については、ウィキペディアの記事を参照してください。