最近Redmineをいじってます。

標準でガントチャートがPDFに出力できたり、作業時間の管理もできるので
Tracよりも使いやすそうかなという印象です。（インストールにはてこずったけどｗ）

とはいえ大量にチケットを登録するのは面倒なので、直接DBのテーブルに書いてます。
他にもっといい方法があるんでしょうけどたどりつかなかった。。。

そこでDBの項目を見ていて気になったのがチケットのデータを登録するissuesテーブルのlft・rgtという項目。

わからなかったのでRedmineから登録したレコードをそのままコピペしていたら、
並列になるハズの子チケットが階層化されてしまいました。

調べてみると、RDBで木構造をあらわす方法のようです。
コチラのページがとても参考になりました。

• SQLアタマアカデミー：第5回　SQLで木構造を扱う～入れ子集合モデル　（1）

実は長いあいだ，木構造の扱いはRDBにとって大きな弱点と言われてきました。二次元表で木のような再帰的構造を表現するうまい方法が見つからなかったからです。
本稿で取り上げるのは，この長年のRDBの弱点を克服できる可能性を秘めた新しい方法論です。その方法の名前は，「入れ子集合モデル（Nested Sets Model）」と言います。［…］

入れ子集合モデルは，RDBの寄って立つ集合概念を，そのまま木構造の記述にも応用できないだろうか，という発想で作られました。その根幹のアイデアは非常に簡単で，次の一文で表現できます。

• 木構造のノードを円（集合）とみなし，階層関係を円の包含関係として捉えなおす。［…］

一次元の点として表現されていたノードを，直径と面積を持つ二次元の円，すなわち集合に見立てることです。［…］

lftとrgtの座標は，円の左端と右端のx座標に相当します

つまり各要素に最小値（lft)と最大値(rgt)を割り振って、lft・rgtの範囲内の要素は子として、範囲外は独立した要素として扱うようです。

元のページには画像ものっていてわかりやすいです。
lftとrgtの名称は、単にleftとrightの略だったみたいですねｗ

これで今回子チケットが階層化されてしまった理由がわかりました。
全ての子チケットのｌｆｔが0、rgtが2のため、階層化されていると判断したようです。
lftとrgtを正しい値に直したら、意図したとおりに表示されるようになりました。

No related posts.