Archief - Simpel DB PK to FK vraagje

Het is ondertussen meer als een jaar geleden dat ik nog eens met databanken heb gespeeld en ik merk dat het meeste gana vliegen is. vandaar mijn vraag die normaal gezien redelijk simpel moet zijn, maar ik blijf fouten krijgen.

Ik heb 3 tabels:

• Klanten
  • klant_id[PK]
  • klant_naam
• Locaties
  • locatie_id[PK]
  • locatie_naam
• KL (relatie tss klant en lokatie)
  • kl_id[PK]
  • kl_klant_id
  • kl_locatie_id

Elke klant kan dus aan een locatie gebonden worden. Nu weet ik niet meer hoe ik een veld een FK maak, want ik krijg de optie tussen PK, unique en index (PHPMYADMIN gebruik ik)

Ik heb ze geindexeert en dan kan ik een relatie leggen met de PK, maar bij de vraag: ON DELETE/ON UPDATE kan ik verschillende keuze's maken (cascade, restrict, set null, no action) en hier krijg ik ook steeds errors. Ik kan hier no action nemen, maar ik veronderstel dat als een klant verwijderd wordt deze row ook in de KL tabel moet verwijderd worden enz..

Ik weet uit het verleden dat dit eigenlijk niet zo moeilijk was, maar ik geraak er niet aan uit.
Kan iemand mij even helpen of linken naar een voorbeeld.

• CASCADE propageert de aanpassing naar de children als de parent verandert (bv. als je de klant delete zullen de gerelateerde records ook gedelete worden)
• SET NULL de gerelateerde records worden op NULL gezet (veronderstelt dat het veld NULL toelaat)
• RESTRICT zal een foutmelding opleveren als je de parent probeert te wissen
• NO ACTION als je MySQL gebruikt is dat hetzelfde als restrict (staat ergens in de MySQL manual) en zal je dus een error krijgen in de zin van "cannot delete a parent row, foreign key constraint fails"

In jouw geval zal je dus in beide gevallen CASCADE moeten gebruiken op je foreign key (die van locatie naar KL en van klant naar KL).

Even terzijde naar je databasestructuur. Op zich is er niets fout met in een tabel "klanten" de naam "klant_id" aan de primary key te geven. Persoonlijk vind ik het echter handiger van de primary key van de table altijd gewoon "id" te noemen en de ids met een prefix (locatie_id, klant_id, &#8230 te gebruiken voor ids van relaties. Je moet dan je primary key naam niet meer afleiden uit je tabelnaam en bovendien is het vooral in abstracties van code wel handig (primary key altijd dezelfde naam, tabelnaam van de relatie afleiden uit de prefix van de foreign key). Is trouwens dezelfde techniek die in veel ORMs worden gebruikt (ActiveRecord, Waterline, &#8230.

Dikke merci.
Zal het even testen of ik het aan de praat krijg. En ivm naamgeving... volledig gelijk. gaat het een pak eenvoudiger maken.

Verder kan je net zo goed de locaties rechtstreeks linken aan de klant (dus klant_id als FK in de locaties) ipv via een tussentabel te werken (tenzij je dezelfde locatie aan 2 of meer klanten zou hangen uiteraard).

Ja de locatie is een instelling. Dus klant x en y kunnen beide in zelfde instelling zitten.