Design for fladt hierarki

Man kan diskutere den løsning til repræsentation af et hierarki, hvor een streng (eet felt) repræsenterer vejen fra toppen til en knude i hiearkiet. Fx.  "1-5-88" - topchefen er nummer 1, afdelingsdirektøren nummer 5, og 88 er den umiddelbare manager. Det giver nogle fordele i søgning, men overtræder første normal form. Er det et ikke for dybt hierarki, er det jo ikke nogen stor overtrædelse ;)

#1 er den nemmeste rent query maessigt, men ogsaa den mest ufleksible fordi den netop
forudsaetter en flad struktur.

#3 giver fleksibiliteten og er ogsaa set mange gange. Queries bliver en lille smule
mere besvaerlige men ikke mere end det kan fixes.

#2 er utilstraekkelig, da den ikke leverer den noedvendige information.

#2 kan dog kombineres med #3 !!

Der er ikke krav om flere niveauer end et. Mit problem er, at jeg kan finde fordele og ulemper for hver af metoderne, og ønsker udenforståendes indsigt/erfaringer til at kunne træffe et valg som jeg kommer til at hænge på et godt stykke tid.

Jeg har ikke specificeret nogen kriterier at veje løsningens "godhed" op imod: det er for at få alskens indspark:)

Man skal holde sig for øje at løsningen også skal være dynamisk - tingene ændre sig hen over tid. Den skal derfor kunne tage højde for situationer som:

1) En person/manager forlader organizationen helt.
2) Der kommer en ny person til.
3) En person (måske allerede en manager) forfremmes.
4) En person flytter et andet sted hen i hierarkiet.
5) Der opstår undergrupper inde i en enkelt department (f.eks. sammensættes en midlertidig tæskeforce).

I alle disse tilfælde skal der tages stilling til hvad der skal ske med persopnerne over og under vedkomende. Alt efter hvordan tabelstrukturen og relationerne er strikket sammen er dette mere eller mindre lige til at gøre med et par velvalgte UPDATE's, eller INSERT's (og måske DELETE FROM hvis man alligevel ikke er interesseret i historikken).

Der er ikke krav om flere niveauer nu, men er du sikker paa at det samme gaelder
om 5 eller 10 aar ?

Det var nogle gode kommentarer.

nielle> 1/2/3/4 er der taget højde for i alle løsningerne, da enhver ændring i hierarkiet må nødvendigvis føre til en opdatering(CRUD minus R) :) 5. er en interessant tanke somjeg ikke havde tænkt på. Til den slags er det min hensigt at anvende roller i en separat tabel, fordi jeg alligevel er nødt til at have en da en Manager også skal kunne udnævne en eller flere AssistantManagers (=Ass.Manager - som mange ville forkorte det til:) som stedfortrædere i systemet. Dvs det er som arne_V's sidste punkt 19/10-2007 19:26:06

arne_V : det drejers sig om godkendelse af ferier/timesedler/fravær/vagter og- ændringer  - i princippet skal cheferne også have deres godkendt af en højere magt, men i praksis ?

Har firmaet ikke allerede alle disse oplysninger i deres AD? Hvorfor ikke bruge dem istedet?

Hvis firmaet vokser, saa kan du vaere helt sikker paa at under-cheferne skal
have godtkendt den slags af over-cheferne.

arne_v  & nielle nu får i mig til at tænke lidt, hvis man nu tager den anden dimension på tværs: projekter. Den må jeg lige gruble lidt over)

nielle>> det er en meget god tanke, og tak for den -  jeg kan desværre ikke besvare den i dette forum.

Du skal heller ikke besvare den, men det er noget du bør have med i tankerne nå4r du skal anbefale en løsning til din opgavestiler (manager).

Jeg har taget bidragene til efterretning, skal blot tænke lidt en dag eller to (sove på det etc etc.) inden jeg afslører den løsning, som alle uden tvivl afventer med stor spænding, hvorpå pointuddelingsritualet vil finde sted.

Nu har jeg kigget på forskellige muligheder og er nået til en lidt anden løsning:

Members skal forblive en flad fil:

Members
-------
MemberID (PK)
MemberName
DepartmentID
..andre Member-data

mens al hierarki gemmes i Departments i stedet for:

Departments
----------
DepartmentID (PK)
DepartmentName
ManagerID(FK fra Members)
evt også AssistantManagerID (FK fra Members)

Hvordan selve hierarkiet skal implementeres (alså info om hvilken afdeling hører under hvilken afdeling)  er ikke klart endnu - enten vha nested sets eller ved erik jacobsens metode. Det med et self-joined felt af typen ReportsTo (eller i dette tilfælde ParentDepartmentID) er pain in the ¤#&, som arne_v nævnte:), fordi det kræver multiple rekursive kald, for at finde alle ancestors eller alle children.

Uanset hvad, så er fordelene ved at lægge hierarkiet andetsteds:

1. Afdelinger og deres relationer ændres overordentligt sjældent, og ved ændringer er der et lille antal records til opdatering
2. En manager ansvarlig for en afdeling behøver ikke at komme fra samme afdeling, og kan optræde som leder for flere forskellige afdelinger(eg. hvor en afdelingsleder også leder nabo-afdelingen, eller hvor divisionschefen også leder en afdeling.)

Den eneste ulempe jeg kan få øje på er, at hver forespørgsel på enten alle overordnede for en Member, eller på alle underordnede for en Manager, nu medfører queries i to tabeller.

to be continued... :)

Du understøtter stadig ikke chefers chefer.

Afdelingerne er hierarkiske, således at Dept=31 & Dept=32 hører under Dept 3, og chefen for Dept 3 vil derfor have rettigheder over alle memberID hvor departmentID=31 v 32 og deres ansvarlige chefer (som fundet i Departments tabellen). Hvordan selve hierarkiet skal stores i db'en er jeg ikke helt klar med endnu.

Okay - jeg får mit hierarki gemt vha Modified Preorder Tree Traversal http://www.sitepoint.com/article/hierarchical-data-database/2, fordi det er så sjældent den ændres, mens den tilgås ret ofte. Rekursive funktioner er noget creepy &/¤# når man debugger, fordi man så får lov til at steppe tilbage gennem hele forløbet ved hver Return;)

Tak for bidragene og alle bedes om at lægge svar.

Måske kunne du have klaret dig uden rekursion i din applikation med en mere standard tabel struktur !?

Og et svar fra mig.

Svar :^)

mangler lige erikjacobsens imprimatur for lukning:)

Nej tak.

jeg ved godt du ikke samler på points, men synes ikke man skal lukke før du har været forbi, så dit bidrag også bliver påskønnet:)

Tak for point :^)