[MySQL/PHP] onduidelijkheid over koppeltabel*

[Verwijderd]

Beste mensen,

Ik ben bezig een registratiesysteem te maken voor een vakantiepark.

Het vakantiepark wil graag bijhouden welke huisjes bezet zijn en welke niet en tot wanneer ze beschikbaar zijn. Als een huisje bezet is, wil het park weten door wie het bezet is.

Ik heb nu dus een DB met 3 tabellen: Tabel Huis (huisid, soort_huis). Tabel Klant (klantid, naam, adres, postcode, woonplaats, telnummer) en tot slot Tabel Verhuur (begindatum, klantid, huisid, einddatum)

Van Tabel huis is huisid de PK.
Van Tabel klant is klantid de PK
en van tabel verhuur is <begindatum, klantid, huisid> een gecombineerde PK. klantid refereert naar klant.klantid en huisid refereert naar huis.huisid.

Tot dit punt ben ik niet zeker over de laatste tabel. Ik weet dus niet zeker of ik wel een gecombineerde sleutel mag maken van sleutels die èn fungeren als onderdeel van een gecombineerde sleutel èn fungeren als een FK.

Het is dus de bedoeling dat als ik een huisje op iemands naam zet, die persoon (databasetechnisch) ook weer de mogelijkheid heeft om later hetzelfde huisje te kunnen reserveren. Indien nodig meerdere huisjes tegelijkertijd te kunnen reserveren. Daar heb ik de koppeltabel Verhuur voor in het leven geroepen.

Aangezien de ondersteuning bij mij op school zwaar belabberd is, zie ik na zoveel pogingen om een goed werkend mysql/php script te krijgen, jullie als laatste hulpmiddel om toch tot een juist werkende php script te kunnen komen.

Waarom kom ik met deze vraag? Tot vandaag heb ik gedacht dat de database geen fouten bevatte. Maar toen ik een insert statement wou maken (???? ik weet niet hoe ????) om in de verhuur tabel een huis toe te kennen aan 1 persoon met begin en einddatum voor de reservering, begon ik vraagtekens te krijgen of die laatste tabel wel goed was, want hoe kan een sleutel (gecombineerd) primary key zijn, maar ook foreign key?

Als jullie vragen hebben (ongetwijfeld) dan hoor ik dat graag!

[whoami]

whoami in "Constraints PK - FK verwijzing vraagje"

[Verwijderd]

Whoami:
Ik zou nooit een primaire sleutel maken, door een combinatie te maken van velden. OK, die combinatie van velden zorgt wel voor een unieke identificatie van dat record, en zou dus in principe geschikt zijn voor een PK, maar dan heb je een probleem met je foreign keys.

Wat voor soort probleem met je foreign keys krijg je dan???

(btw: Mijn welgemeende excuses voor de titel)

[whoami]

Stel je eens voor dat je dus een combinatie van velden als PK gebruikt; velden die echt een betekenis hebben.
Wat ga je dan doen als één van die velden wijzigt ? Dan mag je overal je foreign keys ook gaan aanpassen.

[napel25]

De verhuur tabel is dus geen echte koppel tabel.
Het gewoon een tabel met referenties naar de andere tabellen. Zet daar een autonumber/sequence primary key op en je hebt een prachtig datamodel waar je later op kan voort borduren.

[jochemd]

whoami schreef op woensdag 08 juni 2005 @ 23:01:
Stel je eens voor dat je dus een combinatie van velden als PK gebruikt; velden die echt een betekenis hebben.
Wat ga je dan doen als één van die velden wijzigt ? Dan mag je overal je foreign keys ook gaan aanpassen.

Daar heb je toch cascading updates voor?

[whoami]

jochemd schreef op donderdag 09 juni 2005 @ 12:26:
[...]

Daar heb je toch cascading updates voor?

Cascading updates vind ik maar evil.
Trouwens, daar kan je niet altijd op vertrouwen (zie SQL Server, die die cascading update soms weigert).

[Verwijderd]

een koppeltabel (ik noem het een tussentabel) mag best bestaan uit twee of meer primaire sleutels. Echter wat ik zelf meestal doe is zoiets als dit:

klant:
klant_id
klant_naam

huis:
huis_id
huis_naam

klant_huis:
klant_huis_id
klant_id
huis_id

Dus ook de tussentabel geef ik een eigen PK mee. Maar volgens mij is dit eigenlijk overbodig omdat een gecombineerde PK sleutel in een tabel prima volstaat. Een gecombineerde sleutel combinatie kan dus best wijzigen. Stel je hebt een verhuur ingevoerd op een bepaalde klant_id, huis_id combinatie in de tabel verhuur en je wilt de klant later wijzigen. Dan wijzig je via een update de verhuur tabel (update verhuur set klant = klant_nieuw where huis_id = huis and klant_id = klant_oud)

Maargoed, ik vind het altijd prettig om in elke tabel een eigen PK te hebben. Weet ook niet waarom.

[Verwijderd]

whoami schreef op woensdag 08 juni 2005 @ 23:01:
Stel je eens voor dat je dus een combinatie van velden als PK gebruikt; velden die echt een betekenis hebben.
Wat ga je dan doen als één van die velden wijzigt ? Dan mag je overal je foreign keys ook gaan aanpassen.

Begindatum is inderdaad niet handig maar een primary key met een ingebouwde foreign key is soms wel degelijk handig.

Als de key van de parent tabel redelijk klein is (zeg een autoinc veld) en gecombineert kan worden met één andere kolom kan het combineren zinvol zijn. Hierdoor kun je het aantal indexen op de tabel een beetje beperken (de foreign key moet toch ook geindexeerd worden) Deze aparte index op de foreign key kun je weglaten als de foreign key de eerste kolom is in de primary key.

Niet mijn eigen idee, in de laatste uitgave van IBMs reclameblad (db2mag.com) stond een artikel over PK selectie en de invloed op performance.
http://www.db2mag.com/sto...jhtml?articleID=161601234

[ Voor 5% gewijzigd door Verwijderd op 09-06-2005 12:57 ]

[jochemd]

whoami schreef op donderdag 09 juni 2005 @ 12:28:

Cascading updates vind ik maar evil.

Er zijn een aantal specifieke scenario's waar cascading updates uit de hand kunnen lopen. Denk bijvoorbeeld aan circular referential integrity. Maar over het algemeen is het volgens mij te prefereren boven met het handje constraint deferren, child updaten, parent updaten en committen. Zeker als die updates door meer dan één tabel cascaden.

Trouwens, daar kan je niet altijd op vertrouwen (zie SQL Server, die die cascading update soms weigert).

Wijzen op de fouten van de MS SQL implementatie van referential integrity in een draadje over MySQL. De ironie