[MYSQL] Twijfel opbouw 1-1 relatie - koppeltabel

[Verwijderd]

Hoi,

Na wat nadenken over mijn database layout, stootte ik tegen een probleem. De bedoeling is dat ik een aantal leagues heb, en een aantal gametypes (elk dus in een aparte tabel). De relatie is dat er per gametype een (onbepaald) aantal leagues onderverdeeld zijn.

Eerst had ik deze (heb de overbodige zaken weggelaten) stuctuur:

game
game_id (prim. key)
game_name

league
league_id (prim.key)
game_id (index)
league_name

Maar na wat lezen over normalisatie-methoden, stootte ik op het principe van een koppeltabel. Met het gebruik van een koppeltabel zou mijn structuur er zo uitzien:

game
game_id (prim. key)
game_name

league
league_id (prim.key)
league_name

game_league (de koppeltabel: unieke combinatie)
game_id (prim. key)
league_id (prim. key)

Nu is mijn vraag: voor welke methode moet ik gaan? Ik vond de eerste methode logischer, omdat league lager gerangschikt staat dan game, en dus league afhankelijk is van game. Maar welke methode is nu "de" methode volgens de normalisatie-technieken, want daar kon ik de oplossing niet vinden. Of heeft elke oplossing zijn voor- en nadelen? Welke is het efficiënste om (relatie-) queries mee op te bouwen? Enz...

Ik kan me er echt blind op staren

UPDATE: ik denk dat mijn topictitel fout is.. dit is een 1-N relatie, en geen 1-1 relatie, right? (1 game, meerde leagues daaronder). Zo ja: mod?

[ Voor 0% gewijzigd door Verwijderd op 20-08-2002 00:05 . Reden: foute titel? ]

[judgem]

Ik zou voor de 2de variant gaan maar een tabel met een dubbele primaire sleutel (dus je koppeltabel in de 2de variant) wordt niet door de database geaccepteerd. In jouw geval zou ik in dat geval het game_id primair maken..

* judgem is ook maar een beginner.. Anderen weten het vast beter uit te leggen...

[Verwijderd]

Toch wel hoor.. je legt in principe 1 primary key op 2 velden: zo duid je aan dat de combinatie uniek (game - league) is. Twee+ prim. keys bestaat inderdaad niet, maar je kan je key wel verdelen over meerdere velden. Ik geef toe, ik heb het wat ongelukkig neergeschreven.

Of is het nu echt te warm voor mij?

[Verwijderd]

De oplossing is je relatie.

Je hebt geen relatie tussen game en league, alleen een 1-n relatie tussen league en game. Zie ook je opmerking dat game ondergeschikt is aan league. Oplossing 1 heeft de voorkeur. De koppeltabel zorgt alleen voor meer database activiteit als je een query uitvoert.

[Verwijderd]

Zoals dr2epacs al zei, is de bovenste methode de beste. Je gebruikt een koppeltabel eigenlijk alleen maar als je N-N relaties hebt.

[ Voor 0% gewijzigd door Verwijderd op 20-08-2002 00:25 . Reden: Namen van users goed schrijven ]

[Verwijderd]

Verwijderd schreef op 20 augustus 2002 @ 00:21:
De oplossing is je relatie.

Je hebt geen relatie tussen game en league, alleen een 1-n relatie tussen league en game. Zie ook je opmerking dat game ondergeschikt is aan league. Oplossing 1 heeft de voorkeur. De koppeltabel zorgt alleen voor meer database activiteit als je een query uitvoert.

Dat is inderdaad wat ik dacht/denk, alleen was/ben ik er totaal niet zeker van.

Over die extra dbase activiteit heb je gelijk: het inserten van bijv. een nieuwe league zou in de tweede methode 2 queries (2 tabellen, dus 2 queries) opleveren. Echter gebeurt dit niet vaak.

Verwijderd schreef op 20 augustus 2002 @ 00:24:
Zoals dr2epacs al zei, is de bovenste methode de beste. Je gebruikt een koppeltabel eigenlijk alleen maar als je N-N relaties hebt.

Ok ik ben overtuigd Dankje beiden.

Nog iets: moet ik dan in de tabel "league" game_id als INDEX vastleggen, of een KEY op de combinatie tussen tussen league_id + game_id (want die is immers uniek).

[Verwijderd]

Ik neem aan dat je de league_id uniek wilt hebben, hier moet je dus een primaire sleutel van maken. Een key, index, of primaire sleutel bij game_id (in de tabel league dan) hoeft niet, aangezien dit alleen maar een eigenschap is van de league.

[zneek]

Verwijderd schreef op 20 augustus 2002 @ 00:04:
Eerst had ik deze (heb de overbodige zaken weggelaten) stuctuur:

game
game_id (prim. key)
game_name

league
league_id (prim.key)
game_id (index)
league_name

Maar na wat lezen over normalisatie-methoden, stootte ik op het principe van een koppeltabel. Met het gebruik van een koppeltabel zou mijn structuur er zo uitzien:

game
game_id (prim. key)
game_name

league
league_id (prim.key)
league_name

game_league (de koppeltabel: unieke combinatie)
game_id (prim. key)
league_id (prim. key)

Nu is mijn vraag: voor welke methode moet ik gaan? Ik vond de eerste methode logischer, omdat league lager gerangschikt staat dan game, en dus league afhankelijk is van game. Maar welke methode is nu "de" methode volgens de normalisatie-technieken, want daar kon ik de oplossing niet vinden. Of heeft elke oplossing zijn voor- en nadelen? Welke is het efficiënste om (relatie-) queries mee op te bouwen? Enz...

Ik kan me er echt blind op staren

UPDATE: ik denk dat mijn topictitel fout is.. dit is een 1-N relatie, en geen 1-1 relatie, right? (1 game, meerde leagues daaronder). Zo ja: mod?

Dit is gewoon een 1-N, en dus neemt league de PK van game over. Geen koppeltabel of niks. In bovenstaande oplossing creeer je 3 tabellen, waarvan tussen 2 tabellen een 1-1 relatie is, en dus de tabellen in elkaar geschoven kunnen worden, zodat je dus eerste oplossing weer terug krijgt.

Ik weet niet uit welk boek je de normalisatie methode hebt gehaald die je dat model met 3 tabellen opgeleverd heeft, maar ik zou dat boek weggooien. Of jij moet beter leren lezen. Een koppeltabel krijg je namelijk in een N-N relatie. In jouw geval dus als elke league bij 0,1 of N gametypes kan horen, en een gametype bij 0,1 of N leagues.

[ACM]

Sterker nog, leagues mogen waarschijnlijk niet bestaan zonder dat er een game is?
Dat kan je met dat drie-tabellen model niet eens afdwingen.

[Verwijderd]

zneek schreef op 20 augustus 2002 @ 08:11:
[...]


Dit is gewoon een 1-N, en dus neemt league de PK van game over.

Yup, zie onderaan mijn eerste newspost maar.. was even een foutje

Geen koppeltabel of niks. In bovenstaande oplossing creeer je 3 tabellen, waarvan tussen 2 tabellen een 1-1 relatie is, en dus de tabellen in elkaar geschoven kunnen worden, zodat je dus eerste oplossing weer terug krijgt.

Yup, ik versta het nu, het is hier totaal overbodig door de 1-N relatie.

Ik weet niet uit welk boek je de normalisatie methode hebt gehaald die je dat model met 3 tabellen opgeleverd heeft, maar ik zou dat boek weggooien.

Uit geen boek, maar een samenraapsel van tutorials. Dat is waarschijnlijk ook de reden waarom ik deze (domme?) vraag stelde

Of jij moet beter leren lezen. Een koppeltabel krijg je namelijk in een N-N relatie. In jouw geval dus als elke league bij 0,1 of N gametypes kan horen, en een gametype bij 0,1 of N leagues.

ACM schreef op 20 augustus 2002 @ 08:13:
Sterker nog, leagues mogen waarschijnlijk niet bestaan zonder dat er een game is?
Dat kan je met dat drie-tabellen model niet eens afdwingen.

Inderdaad, een league zonder een gametype kan niet. En dan heb je gelijk ja: in het koppeltabel-geval kan je een league maken, zonder afhankelijk/ondergeschikt te zijn van een gametype.

/me heeft zijn lesje geleerd thanks allemaal

PS: in de tabel league, league_id dan als key en game_id als index, right? (of moet ik rekening houden met de unieke combinatie, en de key leggen op beide velden?)

[ACM]

Ik zou idd league_id als primairy key houden (wat jij key noemt) en game_id als virtuele (aangezien het niet in mysql kan) foreign key (wat jij dus index noemt) maken.

[Verwijderd]

OK!

_{Ja, sorry voor mijn benamingen, het moest allemaal snel gaan}

[zneek]

"En wederom verlaat een tevreden klant het pand"

Herman Finkers - Kussentjes

[Verwijderd]

zneek schreef op 20 augustus 2002 @ 23:59:
"En wederom verlaat een tevreden klant het pand"

Herman Finkers - Kussentjes