Hej Anders.
Konceptet kaldes ind imellem også for en "weak relation" (må ikke
forveksles med OO programmering hvor det ikke er helt det samme) og i
visse tilfælde kan det faktisk give god mening.
Forestil dig at du har f.eks. vælger at have telefonnumre i en separat
"telefon nummer tabel", lad os kalde den tbl_phoneNumber, men at du
samtidigt har mange forskellige entiteter i din database der kan anvende
denne tabel - f.eks. Ordre, Firma, Kontakt, Bruger, og alt muligt andet.
Hvis man skulle lave M2N (mange-til-mange) relationer mellem
tbl_phoneNummber og alle de tabeller der anvender den, så ville det
betyde en ny mellemtabel for hver eneste af dem. Det vil man ikke altid.
Alternativet er så, at benytte den model du selv har observeret. Det
svarer til, at der kun er een enkelt mellemtabel der indeholder en "blød
relation" der kan koble en record sammen med alle de andre tabeller. Det
gøres ved at disse tabellers navn indgå som en del af opslaget. Dermed
sparer man en række tabeller, og får desuden langt nemmere ved at lave
en forespørgsel der kan vise HVOR et enkelt telefonnummer nogen sinde er
blevet brugt/relateret.
Jeg er ikke nødvendigvis selv fortaler af modellen, men den har klare
fordele, og er ikke så mystisk endda
Venligst
- Jesper
Kristian Damm Jensen wrote:
> "Flare" <none@at.all> wrote in message news:<4163f61c$0$232$edfadb0f@dread14.news.tele.dk>...
>
>>Jeg er stødt på følge database design. Er dette normal "skik" at gøre
>>nedenstående.
>>
>>----Addresse----
>>Id
>>FOREIGNID (bigint)
>>IDENTIFIER (varchar(20))
>>Name
>>Street
>>Etc...
>>------------------
>>
>>-- Person ---
>>Id
>>Role
>>Alder
>>etc.
>>-------------
>>
>>Person kender ikke til Addresse mens Addresse i dens IDENTIFIER har en
>>string værdi på fx "person" og så et Person.Id i sin FOREIGNID. Der er også
>>andre IDENTIFIER muligheder fx "order", "kunde" etc.
>>
>>De enkelte entiteter aner ikke at de har en addresse mens addresser kender
>>alle sine "ejere". Jeg synes det virker lidt vanvitigt at have et FOREIGNID
>>som kan pege på en lang række tabeller.
>
>
> Du kan jo overveje alternativet
Fx at have en adresse-tabel for
> hver af de andre tabeller.
>
> Personligt ville jeg nok først lave en supertype til person, order,
> kunde osv. Det ville gøre det lidt nemmere a holde styr på tingene.
>
> Og at personer ikke kender deres adresse er en naturlig følge af, at
> personer (og ikke mindst kunder) kan have flere adresser. Der bør så
> til gengæld være en mulighed for at angive, hvilken adresse man skal
> bruge i forskellige sammenhænge.
>
> Og så er det fjollet, at skrive personId direkte på adressen. Der bør
> være en mange-til-mange relation, hvordan ellers repræsentere flere
> personer på samme adresse? (Med mindre man vil have den samme adresse
> to gange...)
>
> VH
> Kristian