あるIT現場4 昔、沖電気の全部インデックス DB とういのがあった2

あるIT現場4 昔、沖電気の全部インデックス DB とういのがあった2

いやー。縦のDBは、今の現場の担当分には余り向いていない。

何しろカラムが多くなると徐々に遅くなってくる。

計算量が大きい分野なので、レコード数が業務向け横DBに比べると２桁くらい多い。

カラムにキーと数値だけならカラムが少し多くても何とかなるけど。
コード値とか日付を持つカラムが絡んでくると、極端に遅くなる。

何しろ、色んなカラムが沢山あるから、何かの結果を出したり、検索したりするのに、カラムを沢山使う。

すると、横DBの方が早いんじゃないかな。
rollup とか cube ウインドウ関数とか集合関数は早いんだけどな。

業務要件のことをやると。
どうしても、３秒とかかかっちゃうんだよ。
どうして、秒の単位の時間がかかっちゃうのか見えない。

まあ、扱っている量が内部的に、数千万とかに膨らむから仕方ないんじゃないかな。

連係もとのデータ、縦のDBの表定義、縦のDB、戦略ツール。
この組み合わせで、縦のDBの表定義が問題ありだ。
戦略ツールの制限もきつい。

連係もとの横DBをそのまま、使っていることが多い。
また、加工しても、横DB風にしちゃってる。
それは仕方ないかも知れない。

組織階層を縦に並べ替えて、
並べ替えを繰り返し、２次元風にしている。
元は横長だったのかも知れないが。

縦に並べ替えた結果、量が１００倍とかになる。
あることを行おうとすると、重複が発生していまう。
そこに戦略ツールの制限があって、全件処理した後に、
結果を一つだけとかになる。

組織階層は、親子だけにして、親子、孫、・・・
を２次元にする理由は、戦略ツールの制限を避けるためかもしれないが。
重複は回避が難しい。戦略ツールの別な制限がでてくる。

やっぱり、階層は、
階層問い合わせで扱うのが一番だと思う。
階層問い合わせなら、戦略ツールの２つの制限を突破できるのだが。

ある相当できると思われる技術者が、戦略ツールの２つの制限をとっぱするため、
がんばっているのだが。
階層分の制限の回避がからんできて、
終わるのかどうかもわからんらしい。


部品表展開とか、組織階層展開とかでてきたら、
まず考えるのは、部分的に親子ならそれはそのままで、いい。
そして、系列とか知りたいなら、階層問い合わせする。
系列を、２次元の表に展開し直すとかしないほうがいいよ。

月曜日にどうなってるのか。
うまくいってるといいな。