Database Design chef/ondergeschikte relatie

[Remco]

Ik ben een database aan het ontwerpen voor een soort contactenlijst. Heel basic allemaal.
Maar toch heb ik een design vraagje hierover.

Een persoon heeft een leidinggevende.
Deze leidinggevende is natuurlijk zelf ook een persoon met een leidinggevende.
Graag willen wij in het overzicht van een persoon kunnen zien wie de leidinggevende van deze persoon is.
Nu zit ik alleen te twijfelen hoe ik dat zal gaan aanpakken.

1. Zal ik een boolean veld bij personen opnemen om aan te geven of deze persoon wel of niet leidinggevende is ? En een integer veld waarin de ID staat vermeld van zijn/haar leidinggevende. Bij het invoeren van een persoon krijg je d.m.v. een dropdown dan alle leidinggevenden te zien ? Nadeel is natuurlijk dat de leidinggevende moet bestaan voordat je het persoon invoert. Maar dat is niet zo erg.

2. Een tabel personen met een ID veld voor de leidinggevende. En een aparte tabel leidinggevenden. Nadeel hiervan is dat een persoon kan voorkomen in beide tabellen. Een leidinggevende kan natuurlijk zelf ook ondergeschikt zijn aan iemand anders.

3. Een aparte tabel met ID's. B.v. Persoon_ID en Leidinggevende_ID. De leidinggevende ID is dat het Persoon_ID van de leidinggevende.

Volgen jullie mij nog ?
Ik hoop het wel, want ik wil een goed ontwerp neerzetten.
Wie heeft er al eens met zo iets dergelijks te maken gehad ?
Alvast bedankt.

[RobIII]

Als er altijd maar 1 leidinggevende is kun je toch gewoon een parent/child relatie gebruiken? Dan kan alles in 1 tabel ('personen' of 'medewerkers' of whatever). Het wordt wel wat lastig(er) om bijvoorbeeld alle leidinggevenden te vinden, maar ook dat is niet onmogelijk.

[ Voor 48% gewijzigd door RobIII op 25-09-2008 17:35 ]

[Creepy]

Optie 2 maar dan in 1 tabel (of optie 1 zonder boolean) lijkt me een prima oplossing. Vervolgens een LEFT join op dezelfde tabel en je kan prima alle personen met hun chef opvragen.

[Onbekend]

Ik zou 1 tabel gebruiken met de personen, en nog een tabel om de chef-koppelingen te definiëren.
Hiermee heb je een flexibele structuur waardoor je later bijvoorbeeld ook nog eens een chef - adjunctchef - ondergeschikte structuur kan maken.

[ Voor 43% gewijzigd door Onbekend op 25-09-2008 17:47 ]

[Remco]

Creepy schreef op donderdag 25 september 2008 @ 17:36:
Optie 2 maar dan in 1 tabel (of optie 1 zonder boolean) lijkt me een prima oplossing. Vervolgens een LEFT join op dezelfde tabel en je kan prima alle personen met hun chef opvragen.

Dat lijkt me een goede oplossing. Maar bij het toevoegen van een persoon moet ik ook een leidinggevende opgeven. Stel dat dit persoon de eerste is die onder desbetreffende leidinggevende valt. Hoe vul ik dan mijn dropdown met leidinggevenden ?

De tabel zou dan worden:

Persoon_ID

Voornaam

Achternaam

Leidinggevende_ID(is persoon_id van leidinggevende)

Onbekend schreef op donderdag 25 september 2008 @ 17:37:
Ik zou 1 tabel gebruiken met de personen, en nog een tabel om de chef-koppelingen te definiëren.
Hiermee heb je een flexibele structuur waardoor je later bijvoorbeeld ook nog eens een chef - adjunctchef - ondergeschikte structuur kan maken.

Dus dan krijg je tabel personen waar iedereen in staat:

Persoon_ID

Voornaam

Achternaam

En een tabel leidinggevenden:

ID_veld

FK_Persoon_id

Leidinggevende_id(Is persoon_id van leidinggevende

Mis ik nog wel iets waarmee ik mijn dropdown kan vullen met leidinggevenden. Wellicht toch een veldje erbij om aan te geven dat iemand leidinggevend is ?

Ik voel meer voor de oplossing van onbekend.

[ Voor 4% gewijzigd door Remco op 25-09-2008 19:25 ]

[muksie]

Remco schreef op donderdag 25 september 2008 @ 19:24:
Mis ik nog wel iets waarmee ik mijn dropdown kan vullen met leidinggevenden. Wellicht toch een veldje erbij om aan te geven dat iemand leidinggevend is ?

Je zou kunnen overwegen om een tabel Leidinggevenden aan te maken, met (alleen) een FK naar Personen. Je zou dan voor leidinggevenden ook eenvoudig extra informatie op kunnen slaan.

[Creepy]

Iemand is pas een leidinggevende als zijn ID bij een ander voorkomt... meer is echt niet nodig. Een complete boom structuur is zo vrij simpel op te bouwen.... Dit is echt een vrij standaard probleem. Waarom je denkt een boolean veld chef of een extra tabel op te nemen is me een raadsel. Een chef is ook een normale werknemer, niks meer, niks minder.

Waarom wil je zo graag een dropdown met leidinggevenden? Dat kan toch prima een dropdown zijn van alle werknemers? In de toekomst kan iedereen een chef worden natuurlijk....

Op het moment dat iemand daadwerkelijk iemand onder zich heeft komt zijn id voor in de kolom "chef", "leidinggevende", of hoe je die ook noemt. Een select distinct op die kolom levert je alle leidinggevenden op....

[ Voor 17% gewijzigd door Creepy op 25-09-2008 19:53 ]

[Remco]

Creepy schreef op donderdag 25 september 2008 @ 19:52:
Iemand is pas een leidinggevende als zijn ID bij een ander voorkomt... meer is echt niet nodig. Een complete boom structuur is zo vrij simpel op te bouwen.... Dit is echt een vrij standaard probleem. Waarom je denkt een boolean veld chef of een extra tabel op te nemen is me een raadsel. Een chef is ook een normale werknemer, niks meer, niks minder.

Waarom wil je zo graag een dropdown met leidinggevenden? Dat kan toch prima een dropdown zijn van alle werknemers? In de toekomst kan iedereen een chef worden natuurlijk....

Op het moment dat iemand daadwerkelijk iemand onder zich heeft komt zijn id voor in de kolom "chef", "leidinggevende", of hoe je die ook noemt. Een select distinct op die kolom levert je alle leidinggevenden op....

Je hebt gelijk.
Maar het gaat om zo'n 1200 medewerkers met snel zo'n 50 leidinggevenden. Bij het toevoegen van een nieuwe medewerker wil ik graag alleen uit de leidinggevenden kunnen kiezen en niet de hele lijst.

muksie schreef op donderdag 25 september 2008 @ 19:51:
[...]

Je zou kunnen overwegen om een tabel Leidinggevenden aan te maken, met (alleen) een FK naar Personen. Je zou dan voor leidinggevenden ook eenvoudig extra informatie op kunnen slaan.

Kan, maar in dit geval zal de leidinggevende nooit extra informatie krijgen. Ik weet het, zeg nooit, nooit. Maar de kans is heel klein.

[ Voor 17% gewijzigd door Remco op 25-09-2008 19:57 ]

[merauder]

Bouw een query! Dit zou een oplossing wezen wat ik zou gebruiken.

Een tabel met de volgende velden.

code:

ID[Autonummering] ; Naam; Woonplaats; Adres; etc; Leidinggevende [Ja/Nee]

Vervolgens gebruik je een select query om ALLE leidinggevenden er uit te filteren.

In een koppeltabel kan je naar hartelust leidinggevenden aan normale medewerkers plakken als je een relatie definieerd.

Alleen de back-end wordt een hoop geknutsel. Helemaal als je bijvoorbeeld een boomstructuur zou willen.

[Orphix]

Remco schreef op donderdag 25 september 2008 @ 19:56:
Maar het gaat om zo'n 1200 medewerkers met snel zo'n 50 leidinggevenden. Bij het toevoegen van een nieuwe medewerker wil ik graag alleen uit de leidinggevenden kunnen kiezen en niet de hele lijst.

Als je de leidinggevende als ID hebt opgeslagen bij medewerkers kan je een eenvoudig select doen

SQL:

SELECT * FROM Persoon WHERE ID IN 
(SELECT Leidinggevende_ID FROM Persoon)

Om alle leidinggevende te verkrijgen. Dit is tevens waar Creepy op doelde. Een extra boolean (bit) is dus niet nodig.

[Creepy]

merauder schreef op donderdag 25 september 2008 @ 20:49:
Bouw een query! Dit zou een oplossing wezen wat ik zou gebruiken.

Een tabel met de volgende velden.

code:

ID\[Autonummering] ; Naam; Woonplaats; Adres; etc; Leidinggevende [Ja/Nee]

Vervolgens gebruik je een select query om ALLE leidinggevenden er uit te filteren.

In een koppeltabel kan je naar hartelust leidinggevenden aan normale medewerkers plakken als je een relatie definieerd.

Alleen de back-end wordt een hoop geknutsel. Helemaal als je bijvoorbeeld een boomstructuur zou willen.

Leg mij nu eens uit waarom je die boolean leidinggevende hebt en waarom je een koppeltabel zou gebruiken voor een 1:n relatie? Deze oplossing is nu meer dan 1 keer voorgesteld en ik kan me niet voorstellen dat met het volgen van de normalisatie regels je dit een fatsoenlijke oplossing vindt...
Dat boolean veld is zoiezo onzin. Een koppeltabel zou je nog voor kunnen kiezen indien 1 werknemer meerdere leidinggevenden kan hebben (dus een n:m relatie) maar of dat in de praktijk nu echt gebeurd...

Echt, dit is een klassiek schoolvoorbeeld. Met wat googlen kan je hier kant en klare oplossing voor vinden inclusief een shitload aan queries voor het ophalen van werknemers, hun chefs, werknemers zonder chef, chef met 10 of meer mensen onder zich etc. etc. etc.

[ Voor 10% gewijzigd door Creepy op 26-09-2008 09:16 ]

[giMoz]

Het boolean veld is geen onzin. Iemand kan nml leidinggevende zijn, maar nog zonder ondergeschikten.
Iemand moet tenslotte een keer beginnen met leidinggevende zijn.

Anders kan je nml nooit een nieuwe leidinggevende opvoeren.

Met goede normalisatie zou je daar op uit kunnen komen:
regel 1: een medewerker kan leidinggevende zijn
regel 2: een leidinggevende kan ondergeschikten hebben.

zijn twee regels die los van elkaar geimplementeerd moeten kunnen worden. en met alleen een 1:n relatie kan je dat niet oplossen. (tenzij je heeeeeeeel vuil een dummy ondergeschikte opvoert....:N)

[ Voor 44% gewijzigd door giMoz op 26-09-2008 09:43 . Reden: xtra info ]

[beany]

giMoz schreef op vrijdag 26 september 2008 @ 09:40:
Het boolean veld is geen onzin. Iemand kan nml leidinggevende zijn, maar nog zonder ondergeschikten.
Iemand moet tenslotte een keer beginnen met leidinggevende zijn.

Anders kan je nml nooit een nieuwe leidinggevende opvoeren.

En vertel mij dan eens wat een leidinggevende zonder ondergeschikten de hele dag doet??

[giMoz]

beany schreef op vrijdag 26 september 2008 @ 09:42:
[...]

En vertel mij dan eens wat een leidinggevende zonder ondergeschikten de hele dag doet??

Nieuw opgevoerd worden als leidinggevende en ondergeschikten aan zich toegewezen krijgen.
Dat doet ie voor maar heel even, maar dat moet wel kunnen.

[beany]

giMoz schreef op vrijdag 26 september 2008 @ 09:44:
[...]

Nieuw opgevoerd worden als leidinggevende en ondergeschikten aan zich toegewezen krijgen.
Dat doet ie voor maar heel even, maar dat moet wel kunnen.

Iemand is pas leidinggevende als hij/zij ook daadwerkelijk leiding geeft. Je kan geen leiding geven aan niks.

[giMoz]

nee, maar als je dropdownbox om een ondergeschikte een leidinggevende te geven alleen maar gevuld is met mensen die al ondergeschikten hebben kan je nooit een nieuwe leidinggevende aanmaken.

beany schreef op vrijdag 26 september 2008 @ 09:51:
[...]
Je kan geen leiding geven aan niks.

Dat kan wel, iemand kan pas ondergeschikten krijgen als die leidinggevende is.
Het moment tussen leidinggevende geworden zijn, en ondergeschikten hebben is deze dus leidinggevende (of mag leidinggevende zijn) en heeft ie nog geen ondergeschikten.

De boolean zou er alleen maar zijn om nieuwe leidinggevenden aan te maken.
(maar ik sta open voor andere manieren om dat te doen)

[ Voor 58% gewijzigd door giMoz op 26-09-2008 10:09 ]

[Creepy]

Wat ik zou willen weten: waarom zou je dat willen doen? Een persoon heeft een functie. Kan je daar niet uit afleiden dat dit een leidinggevende functie is?

Of wil je dit juist omdat er een lijst getoond moet worden van de leidinggevenden? Want dan zou je je DB structuur laten afhangen van de interface van de applicatie...

Je zult iemand een keer leidinggevende moeten maken, dus je zal de persoon moeten opzoeken en dan het leidinggevende optie aanzetten zodat je daarna via een leidinggevende dropdown deze kan zetten bij een andere persoon. Is het dan niet beter om de zoekoptie voor het aangeven van de leidinggevende direct daar op te nemen i.p.v. alleen een dropdown met leidinggevenden? Dan hoef je voor je DB geen concessies te doen vanwege de userinterface.

[ Voor 40% gewijzigd door Creepy op 26-09-2008 10:24 ]

[Janoz]

Het lijkt me voor de hand liggender om een aparte usecase op te nemen voor het opvoeren van een leidinggevende die nog geen leiding geeft. in 99 van de 100 gevallen is een lijstje met mensen die al een ondergeschikte hebben voldoende. Voor dat ene geval geef je de gerbuiker de mogelijkheid om uit de complete lijst te zoeken.

Er zijn best redenen om zo'n veld in de database op te nemen, maar dit soort userinterface excusjes horen niet bij die goede redenen.

[Jaap-Jan]

giMoz schreef op vrijdag 26 september 2008 @ 10:05:
nee, maar als je dropdownbox om een ondergeschikte een leidinggevende te geven alleen maar gevuld is met mensen die al ondergeschikten hebben kan je nooit een nieuwe leidinggevende aanmaken.


[...]

Dat kan wel, iemand kan pas ondergeschikten krijgen als die leidinggevende is.
Het moment tussen leidinggevende geworden zijn, en ondergeschikten hebben is deze dus leidinggevende (of mag leidinggevende zijn) en heeft ie nog geen ondergeschikten.

De boolean zou er alleen maar zijn om nieuwe leidinggevenden aan te maken.
(maar ik sta open voor andere manieren om dat te doen)

Iedereen is potentieel een leidinggevende. Mijn idee zou zijn om gewoon elke werknemer op te nemen in de dropdownbox, met bovenaan de mensen die op dit moment al leidinggevende zijn.

[Janoz]

Je kunt je energie waarschijnlijk beter steken in een medewerker selectie widget (Denk aan een popupje met een sugestion box oid). Je hebt een userinterface probleem, los het daar dan ook gewoon op.

[Maasluip]

Janoz schreef op vrijdag 26 september 2008 @ 10:26:
Het lijkt me voor de hand liggender om een aparte usecase op te nemen voor het opvoeren van een leidinggevende die nog geen leiding geeft. in 99 van de 100 gevallen is een lijstje met mensen die al een ondergeschikte hebben voldoende. Voor dat ene geval geef je de gerbuiker de mogelijkheid om uit de complete lijst te zoeken.

Dan zou je dus voor iets wat eigenlijk exact dezelfde actie is twee verschillende acties moeten definieren.
Namelijk een actie om een werknemer toe te voegen aan een leidinggevende die nog geen ondergeschikten heeft en een actie om een werknemer toe te voegen aan een leidinggevende die wel al ondergeschikten heeft.
Dat lijkt me juist geen gewenste situatie.

Ik zou eerder een soort "functie_ID" aan elke gebruiker toekennen. 1 = leidinggevende, 2 = medewerker. Dan selecteer je alle gebruikers die leidinggevende zijn.

[Creepy]

Maassluip: die actie is precies hetzelfde: je kent een chef toe aan een werknemer. Of die chef nu al chef is of nog niet maakt helemaal uit niet. In jouw geval moet de gebruiker twee acties uitvoeren bij een nieuwe leidinggevende: eerste zorgen dat hij een leidinggevende is en vervolgens nog bij z'n ondergeschikte de juiste chef zetten. Puur allemaal usecase en UI geneuzel waar je vervolgens je DB op gaat afstemmen.

Als je dat echt nog zou willen defineer dan welke functies leidinggevende functies zijn. Maar aub geen los "leidinggevende optie'" omdat je dat via twee zaken kan afleiden: de functie en het leidinggevende ID bij andere werknemers.

[ Voor 63% gewijzigd door Creepy op 26-09-2008 11:46 ]

[giMoz]

leuke out of the box manieren

En helemaal mee eens dat dat een beter oplossing is.
Grote overeenkomst tussen de oplossingen is: het definieren of iemand chef mag is moet je niet alleen overlaten aan het feit of die ondergeschikten heeft of niet. Maar ergens anders ook nog opslaan (bij voorkeur in de functie)

[merauder]

Creepy schreef op vrijdag 26 september 2008 @ 09:13:
[...]

Leg mij nu eens uit waarom je die boolean leidinggevende hebt en waarom je een koppeltabel zou gebruiken voor een 1:n relatie? Deze oplossing is nu meer dan 1 keer voorgesteld en ik kan me niet voorstellen dat met het volgen van de normalisatie regels je dit een fatsoenlijke oplossing vindt...
Dat boolean veld is zoiezo onzin. Een koppeltabel zou je nog voor kunnen kiezen indien 1 werknemer meerdere leidinggevenden kan hebben (dus een n:m relatie) maar of dat in de praktijk nu echt gebeurd...

Echt, dit is een klassiek schoolvoorbeeld. Met wat googlen kan je hier kant en klare oplossing voor vinden inclusief een shitload aan queries voor het ophalen van werknemers, hun chefs, werknemers zonder chef, chef met 10 of meer mensen onder zich etc. etc. etc.

In die koppeltabel kan je inderdaad de Ondergeschikten aan de leidingevenden koppelen. Maar nu ik net andere oplossingen zag en iedereen een potentiële leidinggevende is (denk aan stagaires/leermeesters., etc) wil ik in deze oplossing toch de boolean droppen.

De koppeltabel heeft echter als doel dat je bij sommige mensen meerdere leidinggevenden wil toekennen, dit zou best handig kunnen zijn in een tijd waarin flexwerken een hot item is.

[Remco]

Was een paar dagen weg, dus excuses dat ik niet aan de discussie mee kon doen.
Ik zal het nog een keer uit de doeken doen.
Wij willen een contactenlijst (intranet) waarin alle medewerkers staan.
Als je het record van een medewerker bekijkt moet je zien wie zijn/haar leidinggevende is.
Niet meer, niet minder.
Er is een selecte groep medewerkers (+/- 3) die hierin mutaties gaat verwerken. De rest mag alleen maar toekijken.
Misschien zal ik het even puntsgewijs neerzetten:

- Een medewerker heeft maar één leidinggevende
- Een leidinggevende kan zelf ook een leidinggevende hebben
- Er zijn vééél leidinggevenden.

Mijn problemen:

- Bij het wijzigen of opnieuw aanmaken van een contactpersoon moet een keuze gemaakt kunnen worden voor een leidinggevende. Ik wil niet alle medewerkers laten tonen, omdat dit er te veel zijn > 1200.
- Als een leidinggevende uit dienst gaat wil ik alle ondergeschikten vrij simpel aan de nieuwe leidinggevende kunnen koppelen.

Het is al met al niet zo'n spannend stukje software, dus ik ben geneigd om een tabel met leidinggevenden aan te maken. Ja, inderdaad een persoon zal dus zowel in de leidinggevenden als in de contactpersonen tabel kunnen voorkomen.
Op deze wijze kan ik vrij eenvoudig een leidinggevende wijzigen.

[pedorus]

Remco schreef op zondag 28 september 2008 @ 21:08:
Mijn problemen:

- Bij het wijzigen of opnieuw aanmaken van een contactpersoon moet een keuze gemaakt kunnen worden voor een leidinggevende. Ik wil niet alle medewerkers laten tonen, omdat dit er te veel zijn > 1200.

SQL:

create view Leidinggevenden as 
    select persoonId, voornaam, achternaam from personen 
    where persoonId in (select baasId from personen)

(En dit is al genoemd door Orphix... Denk aan de aparte usecase bij nieuwe leidinggevenden.)

- Als een leidinggevende uit dienst gaat wil ik alle ondergeschikten vrij simpel aan de nieuwe leidinggevende kunnen koppelen.

SQL:

update personen set baasId=... where baasId=...

[ironisch] Ja, daar is dus echt perse een aparte tabel voor nodig [/ironisch]

Als je al een aparte tabel maakt, dan zou ik daarin alleen persoonId's in opslaan. Een leidinggevende is dan een subklasse van persoon. Dmv foreign keys kun je dan automatisch afdwingen dat iemand die iemands baas is in die tabel moet zitten. Het voordeel is dat je leidinggevenden kan hebben waar nog geen personen onder hangen.

[giMoz]

Een aparte tabel met leidinggevenden lijkt me sowieso een slechte oplossing...

Een boolean, of een functie tabel lijken me een stuk beter geschikt.

[Remco]

pedorus schreef op zondag 28 september 2008 @ 21:55:

SQL:

create view Leidinggevenden as 
    select persoonId, voornaam, achternaam from personen 
    where persoonId in (select baasId from personen)

(En dit is al genoemd door Orphix... Denk aan de aparte usecase bij nieuwe leidinggevenden.)

Dit snap ik ook nog wel. En ja, is inderdaad al genoemd. Zelfs in mijn openingspost. Ik ben gewoon op zoek naar een design, niet naar bijbehorende queries.

Als je al een aparte tabel maakt, dan zou ik daarin alleen persoonId's in opslaan. Een leidinggevende is dan een subklasse van persoon. Dmv foreign keys kun je dan automatisch afdwingen dat iemand die iemands baas is in die tabel moet zitten. Het voordeel is dat je leidinggevenden kan hebben waar nog geen personen onder hangen.

Zie mijn openingspost nr. 3

giMoz schreef op maandag 29 september 2008 @ 06:40:
Een aparte tabel met leidinggevenden lijkt me sowieso een slechte oplossing...
Een boolean, of een functie tabel lijken me een stuk beter geschikt.

Hoe bedoel je functie tabel ? Er moet ook ter herleiden zijn wie de leidinggevende is. Niet alleen of de persoon wel/niet leidinggevend is.

[ Voor 18% gewijzigd door Remco op 29-09-2008 08:22 ]

[giMoz]

Ja natuurlijk een leidinggevende ID in de personen tabel. Dat sowieso, (er van uitgaande dat een persoon altijd maar 1 leidinggevende heeft)

[pedorus]

Remco schreef op maandag 29 september 2008 @ 08:21:
Dit snap ik ook nog wel. En ja, is inderdaad al genoemd. Zelfs in mijn openingspost. Ik ben gewoon op zoek naar een design, niet naar bijbehorende queries.

Nou ja, je hebt dus een relatie tussen 1 object (hier: de leidinggevende) en 1 of meerdere andere objecten van hetzelfde type (hier: de ondergeschikten). Dan volstaat in het algemeen 1 extra kolom in de tabel van dat object en is een extra tabel onzin.
Dat de relatie toevallig naar dezelfde tabel verwijst als waar ie vandaan komt maakt dus niks uit voor het design.

Zie mijn openingspost nr. 3

Nee, daar staat iets met een tabel van de vorm leidinggevende(leidinggevendeId, ondergeschikteId). Ik bedoel een tabel met maar 1 id erin: leidinggevende(persoonId). Dit is dus voor het modelleren van een relatie tussen 1 object (hier: de leidinggevende) en 0, 1 of meerdere andere objecten van hetzelfde type (hier: de ondergeschikten).

[EfBe]

Het is een balanced tree, die je opslaat in een table zoals CELKO al aangegeven heeft in een paar usenet posts (zie hieronder). Het is een typisch textbook voorbeeld om een enkele table te gebruiken met een FK naar self. Dit lijkt leuk maar je kunt er geen reet me in SQL, je kunt nl. niet alle chefs vanaf een bepaald persoon opvragen, er is geen hierarchy opvraag mogelijkheid.

Ik heb zelf vroegah een precalc benadering bedacht die wel werkt, maar wellicht ook over the top is, maar je kunt dan dus wel alle hierarchien opvragen en gewoon normaal inserten.
http://www.llblgen.com/ti...ageID=17746&ThreadID=3208

Je kunt ook CELKO's manier gebruiken met balanced trees. Zie:
http://groups.google.com/...fd1d56858df4?q=tree&pli=1

Ik zou zeker naar Celko's oplossing kijken, de beste man weet nl. alles van sql en set operaties (was ooit chairman van de sql standardization committee). Het klassieke probleem hier nog eens dunnetjes overdoen lijkt me dan ook iewat zinloos, daar er al genoeg over geschreven is. (voor de geinteresseerden, hier een paper met een andere, wellicht toekomstig bereikbare oplossing http://arxiv.org/abs/0806.3115)

[ Voor 11% gewijzigd door EfBe op 29-09-2008 12:14 ]

[MSalters]

Even opletten: iedereen heeft 1 leidinggevende, behalve de CEO. En die kun je niet uit je DB laten, wat anders hebben er een man of 10 geen leidinggevenden meer, en als je die ook gaat weglaten is je database binnen de kortste keren leeg

[BlackIce]

De oplossing zoals hierboven al enkele keren is genoemd lijkt me prima, gewoon een Leidinggevende_ID in de tabel opnemen, dan kun je de leidinggevenden er wel uitpikken.
In veel gevallen zal deze dropdown voldoende zijn.
Als iemand dan iemand die nog geen leidinggevende is leidinggevende wil maken van een bepaald persoon zet je bij het aangeven van de leidinggevende gewoon een knopje bij "Nieuwe leidinggevende" oid? Daarin list je wel alle werknemers, met CSS/Javascript hide je het ding gewoon totdat iemand die knop aanklikt. Als je geen dropdown wilt met alle personen kan je er altijd nog een Autocomplete-iets van maken, kunnen ze nog makkelijk op naam zoeken ook.
Wat betreft de interface zijn er natuurlijk meer oplossingen, maar dan heb je imo iig technisch gezien de handigste oplossing. Hoe je het qua interface doet wil je niet af laten hangen van je Database-opzet.

[Friedje]

Het probleem dat ik zie bij de TS, is dat het functioneel niet helemaal doordacht is...

Wat gebeurt er bijv. als een leidinggevende (manager) vertrekt?
Alle medewerker langs lopen en wijzigen naar de nieuwe medewerker?
En hoe weet je dan nog dat iemand ooit DIE specifieke manager had?

Wij hebben gebruikt gemaakt van een OU (Organisational Unit, zeg maar afdeling)
aan iedere OU koppelen we gedateerd (met begin- en einddatum) een medewerker
als manager.

Je kunt dan door de tijd heen achterhalen wie ooit manager is geweest, nu is, etc.

Daarnaast koppelen we iedere medewerker (ook gedateerd) aan een OU.

En tenslotte geven we bij iedere OU de mogelijkheid om (wederom gedateerd ) een eersthogere OU te koppelen.

Cirkeltje rond volgens mij.

Of... TS heeft het prima doordacht, maar wil niet te uitgebreid modelleren.

[Remco]

Friedje schreef op woensdag 08 oktober 2008 @ 15:41:
Het probleem dat ik zie bij de TS, is dat het functioneel niet helemaal doordacht is...

Wat gebeurt er bijv. als een leidinggevende (manager) vertrekt?
Alle medewerker langs lopen en wijzigen naar de nieuwe medewerker?
En hoe weet je dan nog dat iemand ooit DIE specifieke manager had?

Wij hebben gebruikt gemaakt van een OU (Organisational Unit, zeg maar afdeling)
aan iedere OU koppelen we gedateerd (met begin- en einddatum) een medewerker
als manager.

Je kunt dan door de tijd heen achterhalen wie ooit manager is geweest, nu is, etc.

Daarnaast koppelen we iedere medewerker (ook gedateerd) aan een OU.

En tenslotte geven we bij iedere OU de mogelijkheid om (wederom gedateerd ) een eersthogere OU te koppelen.

Cirkeltje rond volgens mij.

Of... TS heeft het prima doordacht, maar wil niet te uitgebreid modelleren.

Denk het laatste
Het gaat maar om een contactpersonen lijstje.
Vandaar mij opmerking over een tweede tabel met leidinggevenden. Als er één weg gaat, hupsa even de naam veranderen en klaar.

Dus het wordt een tabel met contactpersonen en een tabel met leidinggevenden. Deze koppel ik aan elkaar door in contactpersonen een leidinggevende id-key op te nemen.
De leidinggevende uit de leidinggevende tabel heeft dus geen enkele relatie met hetzelfde persoon in de contactpersonen tabel. Alhoewel IRL het dezelfde persoon is.
Ook hoef ik geen boomstructuren of organogrammen. Ik wil alleen de leidinggevende van een persoon weten, niet meer, niet minder.