Já jsem napsal, že jedno možné zadání je „vedoucí je definován tím, že má podřízené“.
Což je ovšem zadání s odpuštěním nereálné a tedy nesmyslné. Vedoucí pracovník je termín přímo definován zákonem, tento fakt musí být zachycen v pracovní smlouvě, a jsou zákonem dané možnosti, jak se člověk vedoucím stane a jak jím být přestane. Není možné, aby se z někoho stal "nevedoucí" jen tím, že mu odejde z oddělení poslední zaměstnanec. I kdyby existovala firma, kde by to dle tvého nelegálního zadání fakt fungovalo, tak možnost, že dřív či později začnou zákon respektovat je natolik reálná, že je blbost na to aplikaci nepřipravit.
Tak se nediv, že si to ostatní Tvé zadání přeložili do reality.
Špatné implementace zadání se totiž mimo jiné vyznačují tím, že jsou přehnaně obecné, přičemž ta obecnost se nikdy nevyužije
Nu, a proto je třeba, aby ten, kdo navrhuje danou strukturu, o věci něco věděl, jinak není schopen rozlišit obecnost potřebnou od obecnosti "přebujelé".Pokud teda při svém návrhu db ignoruješ legislativu platnou pro daný obor, tak se nediv, že dojdeš k nesmyslným datovým strukturám.
Navíc - viz další odstavec - v normální velké firmě (pro malé se IS zpravidla nedělají) je třeba podchytit v IS daleko více informací (viz další odstavec), takže se do IS firmy hodí daleko flexibilnější datová struktura, než se kterou tady operuješ.
Když se v budoucnosti zadání změní, změníte ten pohled....... jenže pak se změní organizační struktura na maticovou,
A jsme doma. Vyvrátil sis sám vlastní přístup. Samostatný pohled na vedoucí je evidentně nedostatečný - nebo budeš mít jeden pohled na organizační vedoucí a jiný na projektové vedoucí a třetí na....?
Samozřejmě, že rozumný přístup je mít tabulku organizačních jednotek, a funkcí/rolí v organizačních jednotkách. Nejen vedoucích, ale např. schvalovatelů dovolených, sekretářek, a hromady dalších funkcí/rolí, které je třeba zachytit (např. sekretářkám se posílají pokyny o objednávání kancelářských potřeb atpod.). Tak snadno podchytíš jak stromovou strukturu, tak maticovou, nebo i další pitomosti, co si zrovna ředitel ve firmě vymyslí, aniž bys musel překopávat strukturu databáze. Jen max budeš doplňovat číselníky funkcí.
Tvůj přístup, že do struktury db zakóduješ (navíc ilegální) pravidlo, jak určit vedoucího - a pro další role pak budeš vymýšlet jiné další navzájem nekompatibilní adhoc mechanismy, jak je zachytit a vyhledat, to je cesta do pekel... Samozřejmě, na první pohled je Tebou navržené zachycení fce vedoucího jednoduché. Ale v reálu si o takovej návrh db nabiješ čumec.