MySQL model maken met MySQL Workbench
Ik ben begonnen met het maken van een database model voor een uitgebreide site. Alleen begrijp ik het nog niet helemaal hoe het zit met indexes en tabel relaties. Iemand die ook mysql workbench gebruikt en mij kan helpen uitleggen.
Ik ben al wel bekend met de soorten relaties enz maar hoe en wat is me nog niet duidelijk.
Alvast bedankt.
Gewijzigd op 01/01/1970 01:00:00 door Bart van Asselt
Stel je vraag anders eens wat duidelijker, ik zie zelfs geen echte vraag staan, of bedoel dat je niet weet hoe mysql workbench werkt?
Moeten we je dat uitleggen, of wil je wat anders weten? Het is mij ondanks dat ik het wél gelezen heb niet duidelijk, ik kan me de reactie van Hipska dus ook wel voorstellen.
Wat begrijp je niet van indexes en relaties, en wat wil je precies weten daarvan. Als je gerichte vragen stelt kunnen we je daar ook een gericht antwoord op geven, daar is iedereen bij gebaat.
bartjuh schreef op 11.12.2009 12:02:
Hallo mensen,
Ik ben begonnen met het maken van een database model voor een uitgebreide site.
Ik ben begonnen met het maken van een database model voor een uitgebreide site.
Prima! Dit is zeker een goed begin, als je eerst begint met php en dan pas de db maakt zul je veel werk dubbelop doen en bekom je meestal een niet zo optimale database.
Quote:
Alleen begrijp ik het nog niet helemaal hoe het zit met indexes en tabel relaties.
Verstaanbaar, elke beginner heeft het daar moeilijk mee. Als je er niet uitkomt, toon dan even enkele tabellen die met elkaar gelinkt moeten worden en wij zullen proberen jou tips te geven en/of aanwijzing hoe het beter of best kan.
Quote:
Zeker zo'n personen zijn er genoeg. Maar dan moet je eerst wel een vraag stellen die ik moet beantwoorden. Iemand die ook mysql workbench gebruikt en mij kan helpen uitleggen.
Quote:
Ook hier geen probleem om een topic te openen als je ergens niet uit komt..Ik ben al wel bekend met de soorten relaties enz maar hoe en wat is me nog niet duidelijk.
Quote:
Graag gedaan, maar aub niet meer zeggen dat ik je post niet gelezen heb als ik zeg dat er geen vraag in staat.Alvast bedankt.
Ik wil heel graag hulp geven, maar dan moet je met wat meer informatie komen.
bartjuh schreef op 11.12.2009 12:40:
Ik heb niet om je commentaar gevraagd, alleen om hulp met mysql. Maargoed je hebt blijkbaar niets beters te doen dan de boel af te lopen zeiken.
Heb je mijn reactie wel gelezen bartjuh? Ik geef zo al aan dat er een aantal vragen mogelijk zijn te halen uit je topic post. Wat is daar nu precies de vraag uit?
Ik snap het ook niet, het ligt echt niet alleen aan Hipska.
Als je nou je begin post eens uitbreid met een duidelijke vraag wil ik nog wel zo vriendelijk zijn het topic weer op te schonen zodat we met een schone lei kunnen beginnen. Zorg er dan wel voor dat duidelijk is wat je precies wilt weten en wat je precies niet snapt. Stel een duidelijke vraat en waar mogelijk aan de hand van een voorbeeld, zodat men je nog veel beter en duidelijker antwoord kan geven op de vraag.
@Hipska
Laat verder maar even zitten, ik denk dat e.e.a. er niet beter op wordt door steeds weer op elkaar te reageren.
Gewijzigd op 01/01/1970 01:00:00 door Robert Deiman
De vraag is dus, wie kan mij uitleggen wanneer ik een relatie maak tussen tabellen en wat voor relatie.
Het principe is ongeveer zo:
Een tabel met artikels
Een tabel met bestellingen
En een tabel met bestelde artikelen
Je hebt dus een meer op meer relatie tussen artikels en bestellingen met als koppeltabel de bestelde artikelen tabel, want elke bestelling kan meerdere bestelde artikels bevatten. Omgekeerd behoort een artikel ook mogelijks tot meerdere bestellingen.
Je hebt een 1 op meer relatie tussen bestellingen en bestelde artikels, want elk besteld artikel (met bijhorend aantal) kan maar aan 1 bestelbon gekoppeld zijn. Aan 1 bestelbon kunnen wel meerdere bestelde artikels verbonden zijn.
Een 1 op 1 relatie zou je kunnen zien als een relatie tussen bestellingen en leveringsbewijzen. Een leveringsbewijs kan maar aan 1 bestelling gekoppeld zijn en omgekeerd ook.
Normaliseren snap je wel? Want als je normaliseert dan loop je vanzelf tegen koppelingen aan die er moeten zijn. Een koppeling tussen 2 of meerdere tabellen maak je wanneer dat nodig is.
Bijvoorbeeld:
Tabellen:
Adressen
Personen
Voorbeeld 1:
Er kunnen meerdere personen op 1 adres wonen, maar een persoon mag maar op 1 adres ingeschreven staan. Dit betekend dat een adres maar aan 1 persoon gekoppeld mag zijn in je structuur. (denk bijvoorbeeld aan een bestelsysteem van een winkel, waarbij iemand die besteld ook een account heeft)
Hier gebruik je dan dus een 1 op veel relatie, waarbij de 1 op het adres slaat en de veel op de personen. ("veel op 1")
Je hebt hier dan niet persé een extra tabel nodig, maar een kolom "adres_id" in de personen tabel volstaat dan.
Voorbeeld 2:
Er mag maar 1 persoon op een bepaald adres zijn ingeschreven (denk bijvoorbeeld aan een online game waarbij het niet wenselijk is dat meerdere mensen vanaf dezelfde plek zijn ingelogd). Deze persoon mag ook maximaal op 1 adres zijn ingeschreven.
Hier gebruik je dan een 1 op 1 relatie (1 op 1)
Je hebt hier dan een extra kolom nodig in 1 van beide tabellen. Welke tabel maakt niet uit, maar je slaat daar het id van de persoon, dan wel het adres op. (afhankelijk van waar je de extra kolom plaatst)
Voorbeeld 3:
Er mag maar 1 persoon op een bepaald adres staan, maar deze persoon mag wel meerdere adressen hebben.
Stel: contactgegevens voor een contactpersoon die verschillende werklocaties heeft. Per bedrijf/ bedrijfsgroep is er maar 1 contactpersoon.
Hier gebruik je een 1 op veel relatie, waarbij de 1 op de persoon slaat en veel op het adres. ("1 op veel")
Je maakt hiervoor een extra kolom in de tabel adressen. Hierin sla je het id van de persoon die op dat adres staat ingeschreven.
Voorbeeld 4:
Een persoon mag op meerdere adressen zijn ingeschreven en per adres mogen ook meerdere personen ingeschreven zijn. Bijvoorbeeld: Een persoon mag zowel een factuuradres hebben als een bezorgadres.
Op hetzelfde adres mogen ook andere personen zijn ingeschreven.
Hier gebruik je een veel op veel relatie.
Je maakt hier een extra tabel, persoon_adres, waarin je zowel het id van de persoon als van het adres opslaat om ze zo aan elkaar te koppelen.
Het lijkt erop dat je alleen bij de laatste optie een koppeltabel maakt, maar het is aan te raden om dit bij een koppeling waarbij het "eventueel in de toekomst mogelijk is dat de relatie verandert") gewoon een koppeltabel te gebruiken. In het geval van de 1 - op - 1 relatie is het normaliter de gewoonte om geen koppeltabel te gebruiken, maar zoals ik al aangeef: Het is kan waarschijnlijk zijn dat dit nog verandert in de toekomst.
Eigenlijk mnoet je gewoon "vooruit durven kijken" in je structuur. Wat is er in de toekomst mogelijk, of moet mogelijk zijn, qua relaties.
Een koppeltabel heeft als voordeel dat het altijd mogelijk is daar later een 1 op veel of veel op veel relatie van te maken, dus dat je systeem zonder dat je aanpassingen in de structuur van het systeem hoeft te doen, kan je de relaties aanpassen. Het is altijd gemakkelijker om een beetje code aan te passen dan om structuur aan te passen. Daar moet je namelijk op heel veel plekken rekening mee houden.