Reference tabel selvom en-til-mange?

Er det således, at virksomheden har afdelinger i en en-til-mange relation (virksomheden har mange afdelinger, hver afdeling er knyttet til en virksomhed)? og derudover en en-til-mange relation mellem afdeling og bruger (hver afdeling har mange brugere, hver bruger er knyttet til en afdeling)?  I så fald vil jeg foreslå en tabel Virksomheder (som du har lavet) og en tabel Afdelinger med afdelingens id og navn plus et felt virksomheds_id, og en tabel Brugere med brugerens id, navn, rolle, tilladelse, o.s.v., plus et felt afdelings_id.  Derudover har du mulighed for en tabel Roller med id og rollenavn, således at du ikke for hver bruger skal skrive et langt rollenavn men blot en rolle id, og ligeledes en tabel med tilladelser.

Jeg lavede et billede af min foreslåede tabelstruktur som du kan se her:  http://christianjorgensen.be/Billeder/Labisama.PNG

Det at du har en tabel for virksomheden gør, at du har mulighed for bruge strukturen, hvis der en dag skulle komme mere end en virksomhed.

Hvis det er en reel 1:M relation, saa kan jeg ikke se hvad du opnaar ved at splitte den op i to tabeller.

virksomhed----bruger

er glimrende som logisk design (og formentligt glimrende som fysisk design for databaser, som designes med hjaelp fra eksperten.dk).

Hvis du vil have en database struktur som kan haandtere aendringer over tid skal du nok have:

virksomhed----(1:M)----rolle----(M:M)----bruger

hvilket bliver til 4 tabeller (plus evt. support tabeller).

Tak for jeres svar.

Christian > Nej der er ikke nogen afdeling, som sådan. Var egentlig bare en attribut til brugeren som jeg satte på for forståelsens skyld.

Så du må gerne komme med et nyt skud :)

Arne > Jeg havde tænkt mig at splitte den op for overskuelighedens skyld, og for at tabellen "bruger" ikke skulle indeholde alt for meget.

Så du ville synes det er helt at brugertabellen fx. så sådan ud:

Brugere:
- id
- brugernavn
- fornavn
- efternavn
- adresse
- postnr
- email
- virksomhed_id
- rolle_id
- tilladelse
... og så videre.

Så min bekymring er om man mister effekt og/eller overskueligheden ved at have så mange felter i én og samme tabel.

Hvad ville du/I anbefale? Hvad gør I?

Proev for sjovs skyld at udregne hvor mange bytes der er i en raekke og gang det med det antal raekker du forventer og sammenlign saa med dit hardware.

:-)

Og jeg kan ikke umiddelbart se hvorfor det skulle vaere mere overskueligt med to tabeller end med en tabel med mange felter.

Ok, ingen afdeling.  (Så jeg misforstod det du satte på for forståelsens skyld.)  Så er mit bud at finde i dette link:  http://christianjorgensen.be/Billeder/Labisama.PNG .  En sådan en-til-mange relation plejer jeg at modellere med en tabel til eneren, virksomheden, og en tabel til mange-eren, brugeren, som har et felt med virksomheds-id'en.  Det kan så udbygges, hvis man finder det nyttigt, med tabeller med rollenavne, tilladelsesbeskrivelser, og lignende, så man i brugertabellen er fri for at gentage dem og kan nøjes med id'en til den pågældende rolle/tilladelse.

Tvært imod at miste oversigt får du bedre oversigt ved at placere alt hvad der har en en-til-en relation med brugeren i bruger tabellen.  Hvis du ville udbygge og for eksempel gøre plads til adskillige email adresser for hver bruger, således at du skaber en en-til-mange relation mellem bruger og email adresser, og så ville det være hensigtsmæssigt med en særskilt tabel til email adresser der så havde et felt for brugerId.

Du skal sætte dine tabeller op ikke efter det informationsbehov du har i tanker lige nu, men efter den struktur dine data har.  Når du har den rigtige struktur kan du lave dataudtræk der giver dig ikke alene de informationer og præsentationer du havde i tanker til at begynde med, men også informationer du kommer i tanker om hen ad vejen.

Tak for jeres råd begge to.

Arne opret svar, så deler i begge pointene.

svar