[Database ontwerp] Primairy en foreign keys

[Verwijderd]

We zijn bezig met het ontwerpen van een nieuw databasemodel en we komen er niet helemaal uit, we weten het niet meer.

Het gaat om twee tabelen die een 1-op-1 relatie hebben.
Welke tabel krijgt de foreign key?

Dus:
tabel1 en tabel2 hebben elk een primaire key:
tabel1.ID en tabel2.ID

Komt nu in tabel1 de foreign key tabel2ID of komt in tabel2 tabel1ID?
Of maakt het niets uit?

[sjink]

dit is wel erg basiskennis


Modbreak:
Als je niets toe te voegen hebt, post dan niet

[ Voor 65% gewijzigd door gorgi_19 op 19-05-2004 09:18 ]

[whoami]

Euh, dat hangt van de situatie af.

Als tabel1 een tabel is waar de klanten in opgeslagen zijn, en tabel2 is een tabel waar orders van klanten in opgeslagen zijn, dan ga je in de Orders-tabel een foreign key maken naar de tabel klant.
Een klant heeft nl. meerdere orders, maar een order is maar van 1 klant.
Als je het omgekeerd had gedaan, dan had iedere klant slechts 1 order kunnen hebben.

[Verwijderd]

met een beetje googlen kom je er zeker uit. Staat ook in alle databse theorie-boeken.

Modbreak:
Als je zo een post maakt, voeg dan tenminste nog een google linkje toe Met deze opmerking is de topicstarter niets verder geholpen.

[ Voor 52% gewijzigd door gorgi_19 op 19-05-2004 09:18 ]

[NMe]

Een 1:1 relatie komt in een goed databasemodel zelden (praktisch nooit) voor. Misschien tijd om eens wat stof te lezen over het onderwerp?

Bij 1:1 maakt het trouwens idd niet uit waar je de FK zet.

[ Voor 18% gewijzigd door NMe op 19-05-2004 09:07 ]

[NMe]

whoami schreef op 19 mei 2004 @ 09:05:
Euh, dat hangt van de situatie af.

Als tabel1 een tabel is waar de klanten in opgeslagen zijn, en tabel2 is een tabel waar orders van klanten in opgeslagen zijn, dan ga je in de Orders-tabel een foreign key maken naar de tabel klant.
Een klant heeft nl. meerdere orders, maar een order is maar van 1 klant.
Als je het omgekeerd had gedaan, dan had iedere klant slechts 1 order kunnen hebben.

Hij heeft het over een 1:1 relatie, dan zijn er geen meerdere orders.

[whoami]

Hmm, niet goed gelezen.
Een 1:1 relatie, dan ga ik me toch ook wel afvragen wat het nut ervan is.

[NMe]

whoami schreef op 19 mei 2004 @ 09:08:
Hmm, niet goed gelezen.
Een 1:1 relatie, dan ga ik me toch ook wel afvragen wat het nut ervan is.

Niets waarschijnlijk, zoals ik in mijn eerste post ook al zei... Het enige dat ik kan bedenken is dat het dient om een groot aantal optionele velden op die manier buiten de database te houden, maar ik heb het gevoel dat het hier om een slecht databasemodelletje gaat.

[mylar]

De 2 tabellen uit een 1:1 relatie moet je gewoon corrigeren naar 1 tabel. (Toch in 99% van de gevallen)

[gorgi_19]

whoami schreef op 19 mei 2004 @ 09:08:
Hmm, niet goed gelezen.
Een 1:1 relatie, dan ga ik me toch ook wel afvragen wat het nut ervan is.

Er zijn situaties denkbaar waarin je het wel wilt hebben, bijvoorbeeld als je met specifieke modules gaat werken welke later aan een applicatie toegevoegd moeten kunnen worden.

Neem bijvoorbeeld bij mijn applicatie; daar heb je een Company-tabel. En afhankelijk van de specifieke module zijn er verschillende aanvulleningen op de Company-tabel mogelijk.

Om het basisframe intact te laten is er gekozen om met 1:1 relaties te werken.

[Jaspertje]

NMe84 schreef op 19 mei 2004 @ 09:10:
[...]

Niets waarschijnlijk, zoals ik in mijn eerste post ook al zei... Het enige dat ik kan bedenken is dat het dient om een groot aantal optionele velden op die manier buiten de database te houden, maar ik heb het gevoel dat het hier om een slecht databasemodelletje gaat.

Dan nog, al zijn het 1 met veel nulletjes optie velden .. als het een 1:1 is, kan en van de tabellen weg.

De enige mogelijkheid waarom je 1:1 zou willen hebben is dat je db flexibel wilt maken, maar dan is het eigelijk al een 1:n en los je het op in je applicatie.

Voor de TS, kijk welke van de twee kolommen het belangrijkst is en gebruik dat ID in de andere tabel. (Het is zoals je al gelezen hebt niet de mooiste oplossing maar voor jou dan (op je databasemodel aanpassen na) de beste

@gorgi_19 (Ik zal zo je naam ff checken )
Dan nog is het niet het allerbeste db model. Aangezien je er ook voor had kunnen kiezen om gewoon niks met die extra velden te doen die dan wel meegeleverd zouden worden in je db. (Ik wil hiermee niet zeggen dat het slecht is hoor )

[ Voor 15% gewijzigd door Jaspertje op 19-05-2004 09:19 ]

[sjink]

sjink schreef op 19 mei 2004 @ 09:04:
dit is wel erg basiskennis

<font color="blue">
Modbreak:
Als je niets toe te voegen hebt, post dan niet
</font>

tja ben van mening dat als je dit soort dingen nog eens niet weet dan moet je geen databases gaan maken.

BTW 1-1 relaties zijn normaal uit den boze tenzij dat je het doet uit het oogpunt van onderhoudbaarheid.

[gorgi_19]

Jaspertje schreef op 19 mei 2004 @ 09:17:
@gorgi_19 (Ik zal zo je naam ff checken )
Dan nog is het niet het allerbeste db model. Aangezien je er ook voor had kunnen kiezen om gewoon niks met die extra velden te doen die dan wel meegeleverd zouden worden in je db. (Ik wil hiermee niet zeggen dat het slecht is hoor )

Ik kan wel vertellen wat de afwegingen destijds zijn geweest. We hebben de applicatie opgedeeld in twee onderdelen; een frame, welke geldig is voor alle games. Vervolgens zijn de individuele spellen een 'addon' op het frame. En iedere game heeft dan ook zijn eigen karakteristieken.

We wilden het frame graag intact houden en een hele duidelijke scheiding aanbrengen tussen de spellen en het frame. Immers, een fout in het frame kan zorgen dat alles plat ligt; een fout in een add-on zorgt dat alleen maar 1 gedeelte plat ligt. (dit wil niet zeggen dat er geen wijzigingen in het frame meer worden aangebracht; alleen wijzigingen welke in principe beschikbaar moeten zijn voor alle games)

Oftewel: puur een kwestie van onderhoudbaarheid. We kunnen dus wijzigingen / features in spellen aanbrengen, zonder rekening te hoeven houden met de andere onderdelen.

Is het minder netjes? Purtistisch gezien klopt dit; 't is minder netjes. Is het minder onderhoudbaar? Integendeel; je hebt een stuk extra flexibiliteit gekregen.

[ Voor 10% gewijzigd door gorgi_19 op 19-05-2004 09:40 ]

[Verwijderd]

Ik zou zeggen, zoek even een website op over database normalisation. Als je dat wat onder de knie hebt lossen problemen als deze zichzelf op.

[NMe]

sjink schreef op 19 mei 2004 @ 09:22:
tja ben van mening dat als je dit soort dingen nog eens niet weet dan moet je geen databases gaan maken.

BTW 1-1 relaties zijn normaal uit den boze tenzij dat je het doet uit het oogpunt van onderhoudbaarheid.

Voor de onderhoudbaarheid juist niet, hoe meer tabellen met vreemde associaties, hoe onduidelijker de zooi wordt.

Dan nog, al zijn het 1 met veel nulletjes optie velden .. als het een 1:1 is, kan en van de tabellen weg.

Het kan zeker weg... Maar stel: je werkt in MySQL, en hebt een tabel met 20 optionele varchar(40) velden. Zoals je misschien weet maakt MySQL bij varchar(>4) er automatisch char velden van (ik kan je geen link geven, ik geloof dat een van de modjes hier een link naar een anti-MySQL pagina heeft waar dat op staat). Char velden nemen weer altijd de ruimte in die ze maximaal lang mogen zijn, dus dat wordt, ook als je niets invult, 20x40 bytes per record extra. Met een 1:1 relatie vermijd je dat.

Feit blijft dat het in 99 van de 100 gevallen niet nodig is een 1:1 relatie te maken.

[Jaspertje]

NMe84 schreef op 19 mei 2004 @ 09:28:
[...]

Voor de onderhoudbaarheid juist niet, hoe meer tabellen met vreemde associaties, hoe onduidelijker de zooi wordt.


[...]

Het kan zeker weg... Maar stel: je werkt in MySQL, en hebt een tabel met 20 optionele varchar(40) velden. Zoals je misschien weet maakt MySQL bij varchar(>4) er automatisch char velden van (ik kan je geen link geven, ik geloof dat een van de modjes hier een link naar een anti-MySQL pagina heeft waar dat op staat). Char velden nemen weer altijd de ruimte in die ze maximaal lang mogen zijn, dus dat wordt, ook als je niets invult, 20x40 bytes per record extra. Met een 1:1 relatie vermijd je dat.

Feit blijft dat het in 99 van de 100 gevallen niet nodig is een 1:1 relatie te maken.

Kent MySQL geen nvarchar?

[Verwijderd]

@Allemaal:
Bedankt voor alle respons.
Het is me nu ook duidelijk waarom ik niet meer wist hoe dat ook al weer zat met de foreign keys bij een 1:1 relatie.
We heroverwegen het datamodel.
Nogmaals bedankt voor alle reacties

[hiostu]

Een 1-1 relatie zou ook denkbaar kunnen zijn als je tegen 1 van de 2 rij limitaties van SQL-server aanloopt. Een rij van een tabel kan in SQL-server namelijk maar +/- 8000 bytes zijn en een tabel mag maar 1024 kolommen bevatten....

[whoami]

Hmm, inderdaad. In sommige gevallen is het te overwegen, maar zoveel zou het toch niet mogen voorkomen.

Stel, je hebt een tabel 'Klanten', en per klant hou je een memo v/d klant bij (in een (n)text veld, dan is het toch beter om die text-velden niet in je klanten-tabel op te nemen, maar om die in een andere tabel (en in SQL Server misschien ook wel in een andere filegroup) te zetten.

[NMe]

Jaspertje schreef op 19 mei 2004 @ 09:35:
Kent MySQL geen nvarchar?

Mijn versie in ieder geval niet.

offtopic:
Leuk dat een topic met zo'n n00bvraag toch tot een zinnige discussie komt trouwens.

[ Voor 24% gewijzigd door NMe op 19-05-2004 10:10 ]

[sjink]

Ik bedoel uit het oogpunt van ondehoudbaarheid dat, je hebt bijvoorbeeld in tabel 1 een veld wat een aantal vaste waardes kan hebben, dan kun je overwegen om die vaste waardes in een andere tabel2 te zetten. Op deze manier hoef je niet wanneer een van die vaste waardes gewijzigd word in alle tigduizend records in tabel1 die waarde aan te passen, maar pas je die gewoon aan in tabel2

[whoami]

sjink, dat is dan ook geen 1:1 relatie, of in ieder geval beschrijf je daar geen voordeel voor een 1:1 relatie.

[sjink]

whoami schreef op 19 mei 2004 @ 10:04:
sjink, dat is dan ook geen 1:1 relatie, of in ieder geval beschrijf je daar geen voordeel voor een 1:1 relatie.

nee? wat is het dan?

[Creepy]

sjink schreef op 19 mei 2004 @ 10:06:
[...]


nee? wat is het dan?

een 1:n relatie. De "vaste waardes" kunnen namelijk meerdere keren voorkomen in de andere tabel.

Een 1:1 relatie wil zeggen dat 1 record uit de ene tabel bij precies 1 record hoort uit de andere tabel.

offtopic:
wie zei er ook alweer iets over basiskennis?

[ Voor 12% gewijzigd door Creepy op 19-05-2004 10:16 ]

[sjink]

Creepy schreef op 19 mei 2004 @ 10:15:
[...]

een 1:n relatie. De "vaste waardes" kunnen namelijk meerdere keren voorkomen in de andere tabel.

Een 1:1 relatie wil zeggen dat 1 record uit de ene tabel bij precies 1 record hoort uit de andere tabel.

offtopic:
wie zei er ook alweer iets over basiskennis?

Misschien dat ik het niet goed heb uitgelegd maar heb het wel degelijk over een 1-1 relatie
Misschien kan ik even een voorbeeldje bedenken dan is het misschien wat duidelijker

[ Voor 10% gewijzigd door sjink op 19-05-2004 10:20 ]

[whoami]

Dan begrijp ik niet wat je hier mee bedoelt:

Op deze manier hoef je niet wanneer een van die vaste waardes gewijzigd word in alle tigduizend records in tabel1 die waarde aan te passen, maar pas je die gewoon aan in tabel2

Als het een 1 : 1 relatie is, en je moet een aantal waarden updaten, dan moet je in beide situaties evenveel records updaten (of je nu 2 tabellen hebt in een 1:1, of als je nu 1 tabel hebt).

[sjink]

Zie onderstaand voorbeeld: Ik heb bijvoorbeeld orders met een bepaalde prioriteit. Ik heb besloten ipv van in het het veld ORDER.PRIORITEIT gewoon de tekst te zetten bijvoorbeeld 'standard' ofzo, dat ik een verwijzing (foreign key) maak naar een tabelletje waarin alle mogelijk prioriteiten instaan.
Dit heeft als voordeel dat als ik bv. de status STANDARD anders wil gaan noemen (NORMAL ofzo) dat ik alleen in mijn PRIORITEIT tabel een aanpassing hoeft te maken ipv. al mijn tig duizend order records te moeten aanpassen. Of een andere mogelijk situatie ik besluit om de prioriteit termen nederlandstalig te maken ipv engelstalig, dan hoef ik wederom alleen mijn PRIORITEIT tabel even aan te passen.

Hoop dat het nu wat duidelijker is, uitleggen is namelijk niet mijn sterkste punt

code:

TABEL ORDER
------------------------------
|ID | PRODUCTNR | PRIORITEIT |
------------------------------
| 1 | 23434     | 3          |
| 2 | 67657     | 1          |
| 3 | 34545     | 2          |
------------------------------

TABEL PRIORITEIT
-----------------
|ID | TEKST     |
-----------------
| 1 | STANDARD  |
| 2 | LOW       |
| 3 | MEDIUM    |
| 4 | HIGH      | 
| 5 | EMERGENCY |
-----------------

[Creepy]

sjink schreef op 19 mei 2004 @ 10:19:
[...]


Misschien dat ik het niet goed heb uitgelegd maar heb het wel degelijk over een 1-1 relatie
Misschien kan ik even een voorbeeldje bedenken dan is het misschien wat duidelijker

Op deze manier hoef je niet wanneer een van die vaste waardes gewijzigd word in alle tigduizend records in tabel1 die waarde aan te passen, maar pas je die gewoon aan in tabel2

tig duizend records als je 1 waarde veranderd klinkt als een 1:n relatie Of je legt het wel heel krom uit

Ok, je hebt je post aangepast.
En je legt een 1:n relatie uit. Want ik neem aan dat er meerdere orders een standaard prioriteit kunnen hebben

[ Voor 14% gewijzigd door Creepy op 19-05-2004 10:39 ]

[whoami]

sjink,

Dat is dan een 1:n relatie, en geen 1:1 relatie.
Er kunnen nl. meerdere orders zijn met dezelfde prioriteit.

[ Voor 5% gewijzigd door whoami op 19-05-2004 10:37 ]

[sjink]

Hoezo bij iedere order-record is er toch maar 1 prioriteit record betrokken, dat lijkt me toch een 1-1 relatie

[Creepy]

sjink schreef op 19 mei 2004 @ 10:39:
Hoezo bij iedere order-record is er toch maar 1 prioriteit record betrokken, dat lijkt me toch een 1-1 relatie

Maar bekijk het eens andersom. Elk prioriteit record kan meerdere keren voorkomen in de in de order tabel. Dus 1:n

[P_de_B]

sjink schreef op 19 mei 2004 @ 10:39:
Hoezo bij iedere order-record is er toch maar 1 prioriteit record betrokken, dat lijkt me toch een 1-1 relatie

sjink, je moet het niet op het nivo van individuele records bekijken, maar op het nivo van tabellen. De tabellen hebben de 1:n relatie met elkaar.

1 record uit de prioriteiten tabel kan horen bij verschillende records uit de order tabel.

[whoami]

Het is een 1:n relatie, aangezien er verschillende orders kunnen zijn met dezelfde prioriteit.

Een 1:1 relatie is imo een relatie waarbij ieder record uit tabel 1 met juist 1 record uit tabel 2 gerelateerd is, en vice versa.

Als je op je veld 'prioriteit' in de tabel Orders een unique constraint zou leggen, dan zou het een 1:1 relatie zijn.

[sjink]

jullie heb volgens mij idd gelijk, bedankt voor me even iets bij te leren

[CH4OS]

sjink schreef op 19 mei 2004 @ 10:33:

code:

TABEL ORDER
------------------------------
|ID | PRODUCTNR | PRIORITEIT |
------------------------------
| 1 | 23434     | 3          |
| 2 | 67657     | 1          |
| 3 | 34545     | 2          |
------------------------------

TABEL PRIORITEIT
-----------------
|ID | TEKST     |
-----------------
| 1 | STANDARD  |
| 2 | LOW       |
| 3 | MEDIUM    |
| 4 | HIGH      | 
| 5 | EMERGENCY |
-----------------

Maar dan geef je nu zelf je antwoord toch al? Je moet alleen PK (Primary Key, van tabel prioriteit, aan prioriteit hangen, van tabel order... (Waardoor die link dus de FK (Foreign Key) wordt (als ik het goed heb...)

Verwijderd schreef op 19 mei 2004 @ 09:02:
Welke tabel krijgt de foreign key?

Elke tabel heeft (vaak) een primary key, een foreign key, is een link naar een eigenschap in een andere tabel (meestal de primary key van die tabel...)

Komt nu in tabel1 de foreign key tabel2ID of komt in tabel2 tabel1ID?
Of maakt het niets uit?

Het maakt wel wat uit, want je kan immers een m:1 hebben en een 1:m en jij hebt een 1:m waarbij de m volgens mij de foreign key is...

Als ik een beetje heel erg onduidelijk ben moet je het ff zeggen, dan zal ik het nader toelichten

[Creepy]

GJ-tje schreef op 19 mei 2004 @ 10:45:
[...]
Als ik een beetje heel erg onduidelijk ben moet je het ff zeggen, dan zal ik het nader toelichten

Je praat over 1:n of n:1 relaties, en de T.S. had een vraag over een 1:1 relatie. Zoals al gezegd kan in de meeste gevallen een 1:1 relatie vervallen door alles in 1 tabel te stoppen.
Afhankelijk van de entiteiten kan je bij een 1:1 relatie bepalen welke tabel de FK krijgt.

Dat sjink een 1:n met een 1:1 relatie verward moet je verder even buiten beschouwing laten denk ik

[curry684]

Voorbeeld van een 1:1 relatie:

code:

Table Employee
--------------
EmployeeId (PK)
LeaseAutoId (FK)
...

Table LeaseAuto
--------------
LeaseAutoId (PK)
EmployeeId (FK)
...

Dit is een 1:1 relatie omdat er bij iedere single LeaseAuto maar 1 employee kan horen, en bij iedere Employee maar 1 leaseauto. Ik pik express dit voorbeeld omdat het zo goed illustreert waarom een 1:1 relatie vrijwel altijd fout is: in de praktijk zal tijdens de overgangsfase tussen 2 auto's een werknemer vaak 2 auto's op z'n naam hebben staan. De FK LeaseAutoId mag dus in de Employee absoluut niet bestaan, een 1:n relatie zou hier correct zijn.

[sjink]

Ik zat dus gewoon compleet fout met mijn gedachten, toen ik een ERD tekende toen zag ik meteen dat het geen 1:1 relatie was
Wist het dus stiekem wel, alleen waren mijn gedachten een beetje aan t dwalen

[CH4OS]

Creepy schreef op 19 mei 2004 @ 10:49:
[...]

Je praat over 1:n of n:1 relaties, en de T.S. had een vraag over een 1:1 relatie. Zoals al gezegd kan in de meeste gevallen een 1:1 relatie vervallen door alles in 1 tabel te stoppen.
Afhankelijk van de entiteiten kan je bij een 1:1 relatie bepalen welke tabel de FK krijgt.

Dat sjink een 1:n met een 1:1 relatie verward moet je verder even buiten beschouwing laten denk ik

Ja dat had ik al door, dat de T.S. even in de war was...

Maar wat is de n in 1:n...
Ik weet dat je 1 op meerdere bedoelt... Maar waar staat de n voor, want ik zou dan de m gebruiken (Heb dat namelijk zo geleerd...)

[ Voor 3% gewijzigd door CH4OS op 19-05-2004 11:07 ]

[sjink]

m en n zijn beide letters die je gebruikt bij programmeren e.d. voor aantallen groter dan 1
Gewoon een beetje een begrip dus

[ Voor 16% gewijzigd door sjink op 19-05-2004 11:09 ]

[Verwijderd]

Ja dat had ik al door, dat de T.S. even in de war was...

Ik was niet in de war, dacht ik

Dat sjink een 1:n met een 1:1 relatie verward moet je verder even buiten beschouwing laten denk ik

[NMe]

GJ-tje schreef op 19 mei 2004 @ 11:03:
[...]
Ja dat had ik al door, dat de T.S. even in de war was...

Maar wat is de n in 1:n...
Ik weet dat je 1 op meerdere bedoelt... Maar waar staat de n voor, want ik zou dan de m gebruiken (Heb dat namelijk zo geleerd...)

n is gewoon een internationaal teken voor een onbekende waarde. En m wordt ook gebruikt, je hebt de volgende relaties:

1:1
1:n
n:m

Die laatste zul je nooit in die directe vorm in een database vinden, wordt altijd herschreven naar 2 1:n relaties, met een kruistabel.

[CH4OS]

NMe84 schreef op 19 mei 2004 @ 11:10:
n is gewoon een internationaal teken voor een onbekende waarde. En m wordt ook gebruikt, je hebt de volgende relaties:

1:1
1:n
n:m

Die laatste zul je nooit in die directe vorm in een database vinden, wordt altijd herschreven naar 2 1:n relaties, met een kruistabel.

Nee oke, vroeg het me even af...

[Brothar]

Even gekeken voor jouw toepassing: bij 1 frame horen alle games.
Je tabel "Frames" bevat je definities van hét (algemene) frame, op een bepaald moment, na een bepaalde wijziging:
record 1= eerste ongewijzigde frame (tijdstip=x); record 2 =het frame na de eerste wijziging (tijdstip=x+1); record 3 = het frame na een tweede wijziging - op hetzelfde of een nader aspect (tijdstip= x+2), etc.
Het voordeel is dat er games kunnen zijn, die niet "compatable" zijn met de laatste wijziging, en waarvoor een eerder frame de "actieve" is.

Je neemt dus de foreign key naar het desbetreffende frame in je game-record op.
(1:n = bij 1 frame horen 1 of meerdere spellen).

[ Voor 8% gewijzigd door Brothar op 19-05-2004 11:49 ]