Op deze website gebruiken we cookies om content en advertenties te personaliseren, om functies voor social media te bieden en om ons websiteverkeer te analyseren. Ook delen we informatie over uw gebruik van onze site met onze partners voor social media, adverteren en analyse. Deze partners kunnen deze gegevens combineren met andere informatie die u aan ze heeft verstrekt of die ze hebben verzameld op basis van uw gebruik van hun services. Meer informatie.

Akkoord

Vraag & Antwoord

Webprogrammeren & scripting

[PHP & MySQL] Vraag m.b.t. relaties

Anoniem
Wiep Corbier
14 antwoorden
  • Ik ben bezig om PHP en MySQL te leren. Alleen is er één ding waar ik maar niet uit kom, namelijk relaties binnen een MySQL database. Ik heb al verschillende documenten op Internet en boeken doorgelezen. Maar daar vind ik alleen informatie over hoe ik de informatie uit de database haal.

    Het beeld dat ik nu heb aan de hand van een voorbeeld:

    2 tabellen

    tabel 1: Namen
    naam_id; naam; achternaam

    tabel 2: Adressen
    adres_id; straat; nummer; postcode; plaats; naam_cid (om de relatie te leggen);

    naam_id en adres_id zijn auto_increment.

    Wanneer ik nu iemand in de database toevoeg vul ik alle gegevens in een PHP pagina in. Deze voeg ik met de volgende query's toe aan de database.

    Query 1 (Voeg naam toe aan de database):
    INSERT INTO 'Namen' VALUES 'naam', 'achternaam'

    Query 2 (Bepaal naam_id van net toegevoegde persoon. Dit omdat deze in tabel 2 ingevoerd moet worden)
    SELECT 'naam_id' FROM 'Namen' ORDER BY 'naam_id' DESC LIMIT 1

    Query 3 (Voeg adresgegevens en naam_id to aan database)
    INSERT INTO 'Adressen' VALUES 'straat', 'nummer', 'postcode', 'plaats', 'naam_cid'
    naam_cid is dus de waarde uit query 2

    Hoewel dit natuurlijk wel werkt, vind ik dit dus niet erg netjes. Wanneer de database bijvoorbeeld veel gebruikt wordt kan dit tot problemen lijden (toch?). En wanneer ik handmatig de naam_id wijzig zal de ongewijzigd blijven in de Adressen tabel.

    Nu heb ik twee vragen. Hoe gaan jullie hier mee om (hoe hoort het). En hoe kan ik een één op veel relatie maken binnen een MySQL database.

    Mijn dank voor het doorlezen van deze hele lap tekst. Ik hoop dat iemand mij het antwoord kan geven.

    edit:
    Ik gebruik de laatste (stabliele) versie van zowel PHP en MySQL. Om de MySQL databse aan te passen gebruik ik phpMyAdmin.
  • ID ophalen na een insert kan met mysql_insert_id.

    Relaties aanleggen kan via Foreign Keys (check de manual van MySQL). Deze relaties ook afdwingen (Foreign Key Constraints) kan niet met elke mysql-versie cq. table-type, voor zover ik weet. Maar ook dat moet wel in de manual van mysql staan.
  • Maar, zoals ik het doe is geen relatie (even voor de zekerheid).

    In ieder geval bedankt :D
  • [quote:2f910fb1a8="wes_55"]Maar, zoals ik het doe is geen relatie (even voor de zekerheid).
    [/quote:2f910fb1a8]
    In jouw geval is er natuurlijk ook een relatie, alleen is deze niet vastgelegd en/of afgedwongen in de database.
  • [quote:91063c7257="wes_55"]

    Nu heb ik twee vragen. Hoe gaan jullie hier mee om (hoe hoort het). En hoe kan ik een één op veel relatie maken binnen een MySQL database.

    Mijn dank voor het doorlezen van deze hele lap tekst. Ik hoop dat iemand mij het antwoord kan geven.

    [/quote:91063c7257]

    ‘Het antwoord' is wat lastig lijkt mij. Er is niet direct 1 manier waarop het hoort. Check
    eferential constraints hebben voor,- en nadelen. Afhankelijk van je doel gebruik je ze. Wil je alleen voor leerdoeleinden zoiets inbouwen? Het kan handiger zijn je controles op relaties buiten de DB te doen.
    En wat bedoel je precies met 'een één op veel relatie maken'? Je maakt een relatie waarbij de aard van de velden(primary, unique, non-unique) maakt dat een relatie 1-n kan zijn. Of begrijp ik je vraag verkeerd?
  • [quote:c8b8354489="fabiobruna"]
    Check
    eferential constraints hebben voor,- en nadelen.
    [/quote:c8b8354489]Nadelen? Ik ben ze nog tegengekomen.
    [quote:c8b8354489="fabiobruna"]
    Afhankelijk van je doel gebruik je ze. Wil je alleen voor leerdoeleinden zoiets inbouwen? Het kan handiger zijn je controles op relaties buiten de DB te doen.
    [/quote:c8b8354489]
    Hier ben ik het niet mee eens. Als je database FK constraints ondersteunt, dan ben je - imho - niet verstandig bezig als je ze niet gebruikt. Buiten je DB om data controleren mag (moet) altijd, maar de correctheid van de data moet te allen tijde door de DB kunnen worden gegarandeerd. En daarvoor heb je deze constraints nodig.
  • [quote:08ca4657f7="Annie"][quote:08ca4657f7="fabiobruna"]
    Check
    eferential constraints hebben voor,- en nadelen.
    [/quote:08ca4657f7]Nadelen? Ik ben ze nog tegengekomen.
    [quote:08ca4657f7="fabiobruna"]
    Afhankelijk van je doel gebruik je ze. Wil je alleen voor leerdoeleinden zoiets inbouwen? Het kan handiger zijn je controles op relaties buiten de DB te doen.
    [/quote:08ca4657f7]
    Hier ben ik het niet mee eens. Als je database FK constraints ondersteunt, dan ben je - imho - niet verstandig bezig als je ze niet gebruikt. Buiten je DB om data controleren mag (moet) altijd, maar de correctheid van de data moet te allen tijde door de DB kunnen worden gegarandeerd. En daarvoor heb je deze constraints nodig.[/quote:08ca4657f7]

    Ik ben gewoon wat sites in elkaar aan het zetten omwat meer kennis te krijgen. Maar relaties vindt vrij lastig. Met een één op veel relatie bedoel ik bijvoorbeeld persoon1 uit de personentabel heeft meerdere adressen (records) uit het adressen tabel. Maar dit is voor mij meer een database probleem in het algemeen. 1 op 1 lukt wel, moet alleen even vinden hoe dit precies tot stand moet komen.
  • [quote:766afbda44="Annie"]
    Nadelen? Ik ben ze nog tegengekomen.
    [/quote:766afbda44]

    Zonder flauw te willen zijn, dat lijkt mij nauwelijks een reden waarom ze niet kunnen bestaan.

    [quote:766afbda44="Annie"]
    Hier ben ik het niet mee eens. Als je database FK constraints ondersteunt, dan ben je - imho - niet verstandig bezig als je ze niet gebruikt. Buiten je DB om data controleren mag (moet) altijd, maar de correctheid van de data moet te allen tijde door de DB kunnen worden gegarandeerd. En daarvoor heb je deze constraints nodig.[/quote:766afbda44]

    Performance kan een punt zijn. Ben ik tegengekomen :roll: De handleiding van je DB zal de voor en nadelen vast uitgebreider behandelen dan ik kan bedenken.
    Het zijn imho allemaal tools die het rdbms je aanreikt. En dus een keuze om te gebruiken. Een 'best practice' & inderdaad verstandig indien nodig, zeer zeker, maar geen wetmatigheid of standaard om de standaard.

    Just my 2 cents…
  • [quote:9335eca766="fabiobruna"]En wat bedoel je precies met 'een één op veel relatie maken'? Je maakt een relatie waarbij de aard van de velden(primary, unique, non-unique) maakt dat een relatie 1-n kan zijn.[/quote:9335eca766]
    Dat is geen relatie maken. Dat zijn constrains definiëren voor de integriteit van je entity. De relatie is nu nog denkbeeldig (zit in jouw hoofd), maar nog niet gedefinieerd.

    [quote:9335eca766="fabiobruna"]Het zijn imho allemaal tools die het rdbms je aanreikt. En dus een keuze om te gebruiken. Een 'best practice' & inderdaad verstandig indien nodig, zeer zeker, maar geen wetmatigheid of standaard om de standaard.[/quote:9335eca766]Foreign key definiëren is een tool van een RDBMS? Het is de reden van het bestaan van een RDBMS (waar denk je dat de R voorstaat in RDBMS). Zonder foreign key zijn het gewoon losse tabellen, zonder enige relatie met elkaar.

    [quote:9335eca766="fabiobruna"]De handleiding van je DB zal de voor en nadelen vast uitgebreider behandelen dan ik kan bedenken.[/quote:9335eca766]Kun jij mij aanwijzen waar ik dat in de handleiding van bijv. SQL Server of Oracle kan vinden?

    [quote:9335eca766="fabiobruna"]Performance kan een punt zijn. Ben ik tegengekomen :roll:[/quote:9335eca766]Ja, het checken van een foreign key kost tijd voor een RDBMS, maar laat een RDBMS daar nou speciaal voor gemaakt zijn.

    De kans dat je in een situatie komt, waarbij het verwijderen van de foreign key, je laatste poging is om de performance enigzins acceptabel te houden, is vrijwel nihil. Ik heb gehoord van situaties, waarbij dit de allerlaatste redmiddel was (zoals bij AH voor alle informatie van elke klantenbon, wat dagelijks miljoenen records opleverden). In welke situatie ben jij dit tegen gekomen (waar dit écht nodig was)?

    Maar om mijn punt samen te vatten: Waarom adviseer je dit aan iemand die net begint op het gebied van databases?
  • In de hoop dat het enigszins leesbaar blijft kwoot ik er nog kort tussendoor.
    [quote:3859f468f0="Remytje"][quote:3859f468f0="fabiobruna"]Het zijn imho allemaal tools die het rdbms je aanreikt. En dus een keuze om te gebruiken. Een 'best practice' & inderdaad verstandig indien nodig, zeer zeker, maar geen wetmatigheid of standaard om de standaard.[/quote:3859f468f0]
    Foreign key definiëren is een tool van een RDBMS? Het is de reden van het bestaan van een RDBMS (waar denk je dat de R voorstaat in RDBMS). Zonder foreign key zijn het gewoon losse tabellen, zonder enige relatie met elkaar.
    [/quote:3859f468f0]
    Het gaat helemaal buiten het orginele onderwerp van deze draad.. maar daar ben ik het dan niet mee eens. Een relationele database is een database die werkt volgens een relationeel model. Ik meen dat in bijvoorbeeld Oracle FK's in versie 7 zijn geïntroduceerd. Voor die versies werd er echt al gewerkt met relationele modellen. Een relationeel model is een concept, geen techniek.
    [quote:3859f468f0="Remytje"][quote:3859f468f0="fabiobruna"]Performance kan een punt zijn. Ben ik tegengekomen :roll:[/quote:3859f468f0]Ja, het checken van een foreign key kost tijd voor een RDBMS, maar laat een RDBMS daar nou speciaal voor gemaakt zijn.
    De kans dat je in een situatie komt, waarbij het verwijderen van de foreign key, je laatste poging is om de performance enigzins acceptabel te houden, is vrijwel nihil. Ik heb gehoord van situaties, waarbij dit de allerlaatste redmiddel was (zoals bij AH voor alle informatie van elke klantenbon, wat dagelijks miljoenen records opleverden). In welke situatie ben jij dit tegen gekomen (waar dit écht nodig was)?
    [/quote:3859f468f0]
    Dat een rdbms speciaal gemaakt is voor het checken van een foreign key ben ik weer niet met je eens. En ik ben het echt een aantal keer tegengekomen, inderdaad op plekken waar aardig wat regels verwerkt worden en snel er snel rapportages moeten zijn.
    [quote:3859f468f0="Remytje"]Maar om mijn punt samen te vatten: Waarom adviseer je dit aan iemand die net begint op het gebied van databases?[/quote:3859f468f0]
    Dat is een goed punt. Bovendien zijn het uitzonderingen in heel speciale omstandigheden. De suggestie dat iets 'moet' deed het vooral. Gebruik de middelen die je ter beschikking staan altijd met rede en negeer mijn opmerking ook met verstand zou ik zeggen ;-)
  • [quote:060ae13cfb="fabiobruna"]Een relationele database is een database die werkt volgens een relationeel model. [..] Een relationeel model is een concept, geen techniek.[/quote:060ae13cfb]
    Beide opmerkingen kloppen, maar ik hoop dat je het er mee eens ben als ik zeg dat relationele database zonder de mogelijkheid om deze relatie af te dwingen behoorlijk gehandicapped is. Een rdbms bestaat in mijn ogen bij de gratie van de consistentie van de data die de db bevat. Als de database deze consistentie niet kan garanderen, waar blijf je dan met je relationele model? Zonder FK constraints kan de database nooit ACID zijn; iets wat een rdbms in mijn ogen [b:060ae13cfb]moet[/b:060ae13cfb] zijn wanneer de data belangrijk is.
    [quote:060ae13cfb="fabiobruna"]
    Dat een rdbms speciaal gemaakt is voor het checken van een foreign key ben ik weer niet met je eens.[/quote:060ae13cfb]
    Ik denk dat Remytje bedoelde te zeggen dat een rdbms hiervoor is geoptimaliseerd en dat je je dus in het algemeen daar niet zo druk over hoeft te maken.
    [quote:060ae13cfb="fabiobruna"]
    Bovendien zijn het uitzonderingen in heel speciale omstandigheden. De suggestie dat iets 'moet' deed het vooral. Gebruik de middelen die je ter beschikking staan altijd met rede en negeer mijn opmerking ook met verstand zou ik zeggen ;-)[/quote:060ae13cfb]
    Niets 'moet' inderdaad, maar het is wel verstandig om uit te gaan van de regel en niet van de uitzondering.
  • [quote:a458729bf3="fabiobruna"]…maar daar ben ik het dan niet mee eens. Een relationele database is een database die werkt volgens een relationeel model.[…] Een relationeel model is een concept, geen techniek.[/quote:a458729bf3]Net zoals Annie ook al zegt kloppen beide opmerkingen, maar helpen imho jouw standpunt niet :).

    Het relationeel model is een model voor data gebaseerd op vastgelegd wiskundige model. Een relationele database slaat data op volgens dit relationeel model (de data voldoet hiermee aan het vastgelegde wiskundige model).

    Indien je data op [i:a458729bf3]kan[/i:a458729bf3] slaan die niet aan dit relationeel model voldoet, dan is het geen relationele database. Op het moment dat je een ForeignKey-constraint uitschakeld, kan je data opslaan die niet meer voldoet aan dit model (en dat je dat niet omdat je dat ergens anders controleert doet hier niets aan af!)

    Probleem is alleen is dat de meeste relationele databases zich eigenlijk niet zo mogen noemen, omdat ze niet 100% voldoen aan dit model, maar voor mij (en vele andere) defineer ik een relationele database, als een database die in ieder geval de referentiële integriteit kan waarborgen, ook al voldoet deze nog niet 100% aan het relationele model. Maar blijkbaar defineer jij dit anders en vind je databases die nog minder aan het relationele model voldoen nog seeds relationele databases ;)

    [quote:a458729bf3="fabiobruna"]Ik meen dat in bijvoorbeeld Oracle FK's in versie 7 zijn geïntroduceerd. Voor die versies werd er echt al gewerkt met relationele modellen.[/quote:a458729bf3]Als dat waar is, dan was Oracle voor versie 7, geen [b:a458729bf3]R[/b:a458729bf3]DBMS. Zie dan ook niet in hoe dit jouw helpt in je standpunt. Of zoals Annie zegt ;): [i:a458729bf3]'Als de database deze consistentie niet kan garanderen, waar blijf je dan met je relationele model?'[/i:a458729bf3]

    [quote:a458729bf3="Annie"][quote:a458729bf3="fabiobruna"]
    Dat een rdbms speciaal gemaakt is voor het checken van een foreign key ben ik weer niet met je eens.[/quote:a458729bf3]
    Ik denk dat Remytje bedoelde te zeggen dat een rdbms hiervoor is geoptimaliseerd en dat je je dus in het algemeen daar niet zo druk over hoeft te maken.[/quote:a458729bf3]Dat bedoel ik inderdaad.

    [quote:a458729bf3="fabiobruna"]En ik ben het echt een aantal keer tegengekomen, inderdaad op plekken waar aardig wat regels verwerkt worden en er snel rapportages moeten zijn.[/quote:a458729bf3]Je geeft helaas geen concrete voorbeelden, dus ik betwijfel dat je dit [i:a458729bf3]echt[/i:a458729bf3] nodig was. Voor rapportages (SELECT's) worden ForeignKeys-constrains niet ge-checkt, dus zie het nut niet in om ze daarvoor te verwijderen.

    [quote:a458729bf3="fabiobruna"]Bovendien zijn het uitzonderingen in heel speciale omstandigheden. De suggestie dat iets 'moet' deed het vooral. Gebruik de middelen die je ter beschikking staan altijd met rede en negeer mijn opmerking ook met verstand zou ik zeggen ;-)[/quote:a458729bf3]Je kiest moedwillig om niet meer volledig aan het relationele model te voldoen, omdat je mogelijkheden uitgeput zijn om nog een redelijke performance te krijgen. Gevallen waar geen andere mogelijkheden meer zijn, die zijn uitzonderlijk.
  • Was even een tijdje met iets anders bezig, sorry voor de late reactie. Iedereen bedankt voor jullie input, alleen gaat het mij iets te diep.

    Zoals ik het nu begrijp heb ik dus in een tabel een foreign key, dit is een unieke waarde uit een andere tabel. Waardoor er een relatie ligt tussen record's uit beide tabellen. En wanneer ik de unieke waarde wijzig wordt die ook automatisch gewijzigd in de andere tabel. (?)
  • [quote:f1216e824d="wes_55"]Was even een tijdje met iets anders bezig, sorry voor de late reactie. Iedereen bedankt voor jullie input, alleen gaat het mij iets te diep.

    Zoals ik het nu begrijp heb ik dus in een tabel een foreign key, dit is een unieke waarde uit een andere tabel. Waardoor er een relatie ligt tussen record's uit beide tabellen. En wanneer ik de unieke waarde wijzig wordt die ook automatisch gewijzigd in de andere tabel. (?)[/quote:f1216e824d]

    wes_55, ik ben zelf een beginner maar volgens mij moet je de auto increment keys (en keys die hiernaar verwijzen) NIET wijzigen. Dze zij uniek voor elk rij in de database. Je mag alles wijzigen behalve the auto increment keys omdat deze juist de relatie leggen tussen de verschillende tabellen in jouw database.

Beantwoord deze vraag

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.