[mysql] database ontwerpen

[Rusky]

ik zie overal in databasen waar een tabel1 en een tabel2 in een tabel3 word gelinkt dmv de id. maar mijn vraag is hoe doe je dat nu in tabel 3? zet je daar
dan gewoon de id naam van tabel2???

[Verwijderd]

en dus van tabel1

[Rusky]

en die id's moet je indexen ??? of verder helemaal niks bijzonders???

[Alex]

Meestal werkt het als volgt:

code:

Table 1:
-Tbl1_id (PRIMARY)
-Values

Table2:
-Tbl2_id (PRIMARY)
-Tbl1_id (index)
-Values

Table3:
-Tbl3_id (PRIMARY)
-Tbl2_id (index)
-Values

De identifier die van de table is heeft een primarykey. De overigen, waar je op gaat joinen(SELECT t1.*, t2.* FROM Table1 t1, Table2 t2 WHERE t1.tbl1_id=t2.tbl1_id) krijgen een index .

[Grijze Vos]

Dat is compleet afhankelijk van je model. Welke relatie hebben tabel1 en tabel2 met elkaar, daar gaat het om. Bij een veel-op-veel relatie heb je een derde koppel-tabel nodig. Maar dat hoeft niet altijd.

Overzichtje:
(afkortingen: PK = primary key, FK = foreign key

1-1 relatie:
tabel1 heeft de PK van tabel2 als FK,
en tabel 2 heeft de PK van tabel1 als FK.

1-M relatie:
tabel2 heeft de PK van tabel1 als FK,
of (afhankelijk van welke de 1 is, en welke de M) tabel1 heeft de PK van tabel2 als FK.

M-M relatie:
tabel3 bevat de PK's van tabel1 en tabel2 als FK's. Waarbij dus meerdere instanties van tabel1 met meerdere instanties van tabel2 gekoppeld kunnen worden.

[ Voor 55% gewijzigd door Grijze Vos op 10-02-2004 09:46 ]

[Pino]

Zoals ik je verhaal lees is het verstandig dat je wat boeken of sites over (relationeel) database ontwerp en normaliseren gaat lezen.

Dit topic kan ook interessant zijn: Correct database ontwerp, koppeltabellen altijd?

[ Voor 34% gewijzigd door Pino op 10-02-2004 11:33 ]

[Verwijderd]

Note:

MySQL kan zelf niet checken of er een relatie is tussen verschillende tabellen.
Een Primary key en een Foreign key.. die link moet je met behulp van PHP leggen.
In Oracle bijvoorbeeld, kan dat wel "automagisch".

stel:

tabel-users veld-id : tabel-berichten veld-user_id
PRIMARYKEY id : FOREIGNKEY user_id

Als id NIET bestaat in users, mag er NIET geINSERT worden in berichten.

//edit, check zeker even wat tutorials op het net ! Database ontwerp is erg belangrijk.. is de blauwdruk van je website..

[ Voor 15% gewijzigd door Verwijderd op 10-02-2004 11:50 ]

[Rusky]

vanavond ga ik aan het stoeien met de database ... maar voordat ik
dat wou gaan doen wou ik even deze vraag stellen, en bedankt allemaal
het gaat nu zekers te weten lukken ...

[Verwijderd]

Use search en zoek op 'normaliseren'

[Rusky]

heb nu uit eindelijk een tabel structuur in elkaar gezet.
deze is voor om publicaties van documenten in verschillende
talen te publiceren (er is ook onderscheid gemaakt tussen
tijdschriften omdat deze toch bepaalde meta data heeft.



en wat vinden jullie ervan???

[BrZ]

Rusky schreef op 12 februari 2004 @ 14:53:
heb nu uit eindelijk een tabel structuur in elkaar gezet.
deze is voor om publicaties van documenten in verschillende
talen te publiceren (er is ook onderscheid gemaakt tussen
tijdschriften omdat deze toch bepaalde meta data heeft.

[afbeelding]

en wat vinden jullie ervan???

Je hebt 2 tabellen met dezelfde Primary key Das niet goed in ieder geval

Grijze Vos schreef op 10 februari 2004 @ 09:43:
1-1 relatie:
tabel1 heeft de PK van tabel2 als FK,
en tabel 2 heeft de PK van tabel1 als FK.

1:1 relatie is onzin, dat betekent dat het in dezelfde tabel gezet kan worden.

[zeroxcool]

BrZ schreef op 12 februari 2004 @ 15:22:

1:1 relatie is onzin, dat betekent dat het in dezelfde tabel gezet kan worden.

Hoho, dat ligt er maar net aan wat je wilt. Stel een medewerker mag één auto van de zaak hebben en een auto behoort maar tot één medewerker. Zet je de auto's dan bij de medewerkers? Of houd je twee tabellen, dan heb je nog hetvolgende probleem, komt de autoid bij de medewerker, of komt medid bij de auto.

[djlinsen]

ZeRoXcOoL schreef op 15 februari 2004 @ 23:07:
[...]

Hoho, dat ligt er maar net aan wat je wilt. Stel een medewerker mag één auto van de zaak hebben en een auto behoort maar tot één medewerker. Zet je de auto's dan bij de medewerkers? Of houd je twee tabellen, dan heb je nog hetvolgende probleem, komt de autoid bij de medewerker, of komt medid bij de auto.

Niet alle medewerkers zullen een auto hebben, dus apparte tabel met medid in de auto tabel lijkt mij.

[Verwijderd]

ZeRoXcOoL schreef op 15 februari 2004 @ 23:07:
[...]

Hoho, dat ligt er maar net aan wat je wilt. Stel een medewerker mag één auto van de zaak hebben en een auto behoort maar tot één medewerker. Zet je de auto's dan bij de medewerkers? Of houd je twee tabellen, dan heb je nog hetvolgende probleem, komt de autoid bij de medewerker, of komt medid bij de auto.

Dit is een mooi vraagstuk, want is het zo dat iedere medewerker standaard een auto heeft? Dat soort dingen moet je je nou afvragen als je een database ontwerpt en dus kom je in de meeste gevallen tot de conclusie dat dat niet zo is.

De koffie-juffrouw komt met de fiets bijvoorbeeld.

En dan staat de medewerker_id in de tabel auto

Ik bemerk dat de topicstarter zich wil gaan verdiepen in SQL en het linken van tabellen een tip ipv:

SELECT id, achternaam FROM medewerker

doe om problemen te voorkomen

SELECT m.id AS id, m.achternaam AS achternaam FROM medewerker m

Bij veel programma's zie je ook dat bovenstaande suggestie is opgelost door de velden een prefix te geven als m_ welke vastgelegd is in het database ontwerp

[curry684]

BrZ schreef op 12 februari 2004 @ 15:22:
[...]

1:1 relatie is onzin, dat betekent dat het in dezelfde tabel gezet kan worden.

Regel 1 van normalisatie: if it ain't dependent on the primary key it shouldn't be there.

Al hebben alle medewerkers een leaseauto: de properties van die auto horen niet in tabel Employee te hangen, want dan zou je een EmployeeID nodig hebben om een auto te identificeren in je tabel Boete, wat volledig conflicteert met alle concepten achter normalisatie.

Voor koppeltabellen zie trouwens ook [rml]curry684 in "[ SQL] bitselectie enum/set->algoritme *"[/rml].

[BrZ]

curry684 schreef op 16 februari 2004 @ 00:45:
[...]

Regel 1 van normalisatie: if it ain't dependent on the primary key it shouldn't be there.

Al hebben alle medewerkers een leaseauto: de properties van die auto horen niet in tabel Employee te hangen, want dan zou je een EmployeeID nodig hebben om een auto te identificeren in je tabel Boete, wat volledig conflicteert met alle concepten achter normalisatie.

Voor koppeltabellen zie trouwens ook [rml]curry684 in "[ SQL] bitselectie enum/set->algoritme *"[/rml].

Mwa, je kan ook te ver gaan met op splitsen. Dan zou je ook het adres van een medewerker in een aparte tabel kunnen zetten met daarin zijn postcode en huisnummer, waar je naar toe verwijst met een adresid oid.
Maar in geval van de lease auto kan het wel handig zijn, alhoewel ik eigenlijk weinig technische voordelen kan bedenken als je het splits, in het geval dat iedereen altijd 1 lease-auto heeft

[curry684]

BrZ schreef op 16 februari 2004 @ 01:22:
[...]
Mwa, je kan ook te ver gaan met op splitsen. Dan zou je ook het adres van een medewerker in een aparte tabel kunnen zetten met daarin zijn postcode en huisnummer, waar je naar toe verwijst met een adresid oid.

NAW-gegevens horen inderdaad in een aparte tabel ja Dat staat je namelijk toe om bijv. bij Customer een veld FactuurAdresID en AfleverAdresID te maken en zo Not to mention dat je vervolgens in de routeplanning van je logistiek overal kunt verwijzen naar de betreffende adressen, en dat de historische routeplanningen geldig blijven ook na het verhuizen van een klant, wat een probleem zou zijn als je het wel in de klant zelf opsloeg.

Maar in geval van de lease auto kan het wel handig zijn, alhoewel ik eigenlijk weinig technische voordelen kan bedenken als je het splits, in het geval dat iedereen altijd 1 lease-auto heeft

En toen kwam op een dag iemand die wegens wat contractuele problemen 2 weken 2 leaseauto's op z'n naam had staan, of die net in dienst is en z'n auto nog in bestelling heeft...

Design for the future, not for the past

[BrZ]

* BrZ ziet het licht