/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Problem ang. database design.
Fra : Flare


Dato : 03-10-04 15:10

Jeg er ved at designe en database og er støt ind i et problem. Jeg håber i
"eksperter" lige vil afsætte et par minutter til at gennemskue min
problematik

Dette er et tænkt eks som dog illustrere pointen. (Jeg designer til MS SQL
2000)

--- Unit ---
id (pk)
name
-----------

Ok jeg har en Unit. Så har jeg to typer personer (med helt forskellige
egenskaber) som kan "lave" Units

-- PersonAnnonym ---
id (pk)
idnr
afdelingnr_fk (FK)
----------------------

-- PersonNormal ---
id (pk)
navn
addresse
etc.
------------------

Ok. de 2 yper personer kan aflevere en unit men hvordan holder jeg styr på
hvem der har afleveret den konkrete unit. Jeg har flere løsninger men ingen
af dem er gode synes jeg.

1. Jeg opretter 2 ekstra felter i unit: PersonAnonym_FK og PersonNormal_FK.
Dette vil dig betyde at 50% disse felter vil være NULL.
2. Jeg opretter 2 mellemtabeler som i en mange-til-mange relation som så
mapper "Units / PersonNormal" og en som mapper "Units / PersonAnnonym". Og
så er jeg i hvert fald sluppet for NULL værdier men har øget kompleksiteten
en del. Derudover ser jeg det som et problem at de enkelte units ikke "ved"
hvem de hører til og jeg ser en farre i det lange løb for fejl, da man fint
kan oprette Units uden tilknytning til nogen hvilket ALDRIG må ske.

Har i nogen forslag / anbefalinger om hvad man gør i sådan en situation?

Mvh
Anders







 
 
Kristian Damm Jensen (03-10-2004)
Kommentar
Fra : Kristian Damm Jensen


Dato : 03-10-04 19:18

"Flare" <none@at.all> wrote in message news:<4160084d$0$287$edfadb0f@dread14.news.tele.dk>...
> Jeg er ved at designe en database og er støt ind i et problem. Jeg håber i
> "eksperter" lige vil afsætte et par minutter til at gennemskue min
> problematik
>
> Dette er et tænkt eks som dog illustrere pointen. (Jeg designer til MS SQL
> 2000)
>
> --- Unit ---
> id (pk)
> name
> -----------
>
> Ok jeg har en Unit. Så har jeg to typer personer (med helt forskellige
> egenskaber) som kan "lave" Units
>
> -- PersonAnnonym ---
> id (pk)
> idnr
> afdelingnr_fk (FK)
> ----------------------
>
> -- PersonNormal ---
> id (pk)
> navn
> addresse
> etc.
> ------------------
>
> Ok. de 2 yper personer kan aflevere en unit men hvordan holder jeg styr på
> hvem der har afleveret den konkrete unit. Jeg har flere løsninger men ingen
> af dem er gode synes jeg.
>
> 1. Jeg opretter 2 ekstra felter i unit: PersonAnonym_FK og PersonNormal_FK.
> Dette vil dig betyde at 50% disse felter vil være NULL.
> 2. Jeg opretter 2 mellemtabeler som i en mange-til-mange relation som så
> mapper "Units / PersonNormal" og en som mapper "Units / PersonAnnonym". Og
> så er jeg i hvert fald sluppet for NULL værdier men har øget kompleksiteten
> en del. Derudover ser jeg det som et problem at de enkelte units ikke "ved"
> hvem de hører til og jeg ser en farre i det lange løb for fejl, da man fint
> kan oprette Units uden tilknytning til nogen hvilket ALDRIG må ske.
>
> Har i nogen forslag / anbefalinger om hvad man gør i sådan en situation?

Dit problem er et standard sub-/supertype problem.

En almindelig måde at løse problemet på er at oprette en supertype for
dine to persontyper.

-- Person ---
id (pk)
personType
----------------------

-- PersonAnnonym ---
id (pk) (FK refererer Person)
idnr
afdelingnr_fk (FK)
----------------------

-- PersonNormal ---
id (pk) (FK refererer Person)
navn
addresse
etc.
------------------

En del af pointen er, at PersonAnonym.id og PersonNormal.id kommer fra
samme nummerserie, nemlig Person.id.

Du kan herefter bruger Person.id som referende til dine units.

Hvirker det kompliceret? Det er det ikke, og jeg har brugt teknikken
og set den brugt i utallige sammenhænge.

VH
Kristian

Flare (03-10-2004)
Kommentar
Fra : Flare


Dato : 03-10-04 19:33

> En del af pointen er, at PersonAnonym.id og PersonNormal.id kommer fra
> samme nummerserie, nemlig Person.id.
>
> Du kan herefter bruger Person.id som referende til dine units.

Det lyder umiddelbart som en god ide. Jeg ser dog et problem. Når jeg står
med et Person,Id (super typen) hvordan finder jeg så dens subtype reference.
Jeg blive så nød til at søge i begge tabeller. Er det ikke et problem?

Anders



Kristian Damm Jensen (03-10-2004)
Kommentar
Fra : Kristian Damm Jensen


Dato : 03-10-04 20:40


Flare wrote:
> > En del af pointen er, at PersonAnonym.id og PersonNormal.id kommer
fra
> > samme nummerserie, nemlig Person.id.
> >
> > Du kan herefter bruger Person.id som referende til dine units.
>
> Det lyder umiddelbart som en god ide. Jeg ser dog et problem. Når
jeg står
> med et Person,Id (super typen) hvordan finder jeg så dens subtype
reference.
> Jeg blive så nød til at søge i begge tabeller. Er det ikke et
problem?

Hvad tror du Person.personType skal bruges til

Det er redundant, men indsættes netop for at undgå det problem du
beskriver. Som *er* et meget reelt problem. Jeg har set systemer gå i
knæ fordi man var nødt til at lave joins for at analysere subtypen.
VH
Kristian


Flare (03-10-2004)
Kommentar
Fra : Flare


Dato : 03-10-04 20:48

>Hvad tror du Person.personType skal bruges til

>Det er redundant, men indsættes netop for at undgå det problem du
>beskriver. Som *er* et meget reelt problem. Jeg har set systemer gå i
>knæ fordi man var nødt til at lave joins for at analysere subtypen.

Ja der er jo problerm er løsningen. Fx kan jeg ikke lave constraints på at
en unit kun skal kunne tilknyttes én person. Måske med noger trigger værk
men ellers ikke. Men jeg køber den. :) Jeg kan ikke komme på en bedre
løsning end din så mange tak :=)

Mvh
Anders




Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408925
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste