一昔前の組織構造はヒエラルキーの構造をしていて、命令系統は上意下達で、稟議・報告系統は下意上達なのでシンプルでした。
RDBでのデータ設計も、部品の構成体系と類似の仕組みが流用できて扱い易かったです。
部品の構成関係の子部品展開などと同様に、再帰的に展開すればよいし、ツリー構造が成立しているので言語でロジックを組んでも便利でした。
最近の組織は、複数の部署を一人が面倒みたり、一人の従業員が複数の部署に所属したり、勤務命令の系統と、仕事命令の系統が別だったり、複数のプロジェクトに所属すると、上司が複数存在することになるそうです。
学校の担任も、一つのクラスに複数の担任がいたり、そのうちの一人は、複数のクラスの担任だったりします。
従来の組織の仕組みが使えません。
一人の上司が複数存在すると、 固定SQLで処理するには、副問い合わせするか、、上位部署を複数保持するList型にして言語処理するなどの対応になります。
双方向リストをデーブルに実装すれば、追跡処理は可能になります。
でも、このような階層構造の過去蓄積は少ないらしく、試行錯誤で設計しているプロジェクトもあるようです。
「サンプルがないから、できません」....などと脳天気なことを言ってくる開発者もいるようで....これは棚に上げるとして...いつ下ろすかは問題ですが。
DataBaseの教科書には、「n:n は n:1 と1:n に帰結できる。1:nを押さえれば レコード設計はできる」とあるようですが、(そのように習ったそうです。)
上司が複数の部下を持ち、その部下は複数の上司を持つという、構造では、単純なn:1..1:n の図式に該当するような、しないような....。ツリー構造とは言いませんよね。
上司が複数、部下も複数ということは、家系図に相当しそうですね。家系図構造と言った方が近いかな。
家系図はRDBで一意に設計できるのだろうか。RDB的には向いてないように思うのです。
自分の 部下が複数いるときは、 where 上位者 = 私 で n件引っ張れますが、
自分の上司が複数いるときは、 where code in (select 上位者 where code=私) とでもしましょうか。
でも同時に取得しようとしたら......できないようなできるような...orz;
今後も、もっと複雑なパターンが登場するのでしょうね。
少し話がずれるのですが。
SQLはヒエラルキー型であっても、なくても select文の要素は事前に確定していることが 条件なので
select 部下1,部下2,部下3,,,,, from Table where code=私
select 上位者1,上位者2,上位者3,,,,, from Table where code=私
などと、要素が複数あるときは、チト困ります。 言語でLOOP回しするのが安易ですが、SQL内でSQLを生成する動的SQLも一つの方法ですね。
言語の受け持ち範囲と、SQLの受け持ち範囲の境界線の設定も、プロジェクト開発効率の大きな要素だと思います。