August 2009 – Jan Verkoyen

Foreign Key Constraints en Display fields in phpMyAdmin

Een van de handigheden in phpMyAdmin is dat je bij een aantal storage engines zoals innoDB en myISAM een ‘display field’ kan instellen.

Het display field is eigen aan phpMyAdmin en heeft niets met mySQL te maken. Wanneer je een display field aanmaakt via phpMyAdmin zal zich dat niet vertaald zien in bvb mySQL Workbench.

Bij INNODB kan dit ook nog een extra aanvulling zijn op foreign keys .

Bij het invoegen van een record wordt automatisch een drop down lijst gegeven van de mogelijke opties wanneer een relatie gelegd is naar een andere tabel. Indien een foreign key constraint bestaat voor een bepaald veld wordt niet alleen een ID getoond naar de verwijzende tabel, maar ook een omschrijving (display field) van de verwijzende tabel. Dit biedt het voordeel dat je niet eerst de verwijzende tabel moet openen en daar gaan zoeken naar de juiste ID.

Laten we uitgaan van het voorbeeld dat je ook op Wikipedia kan terugvinden. Een tabel waarin je de namen van je klanten bewaart en een tabel waarin de bestellingen van alle klanten opgesomd zijn. Elke bestelling wordt geplaatst door een bepaalde klant. In de bestellingentabel definiëren we dus een foreign key naar de tabel klanten.

Tabel 1: klanten

id
naam

Tabel 2: bestellingen

id
artikel
klant (foreign key naar klanten.id)

Het ‘display field’ instellen gebeurt in de ‘relation view’ van de verwijzende tabel (namelijk klanten). Deze relation view is toegankelijk in het structuur menu van de tabel. Als display field kies je in dit geval dus ‘naam’.

Wanneer je nu bestellingen gaat invoeren via phpMyAdmin krijg je bij het invulveld klant een dropdown lijst te zien met de namen (en bijhorende id) uit de klantentabel. Het voordeel is dus dat je niet in een apart venster eerst de id moet gaan opzoeken die bij een bepaalde naam hoort.

Als je meer dan 200 klanten hebt, zal er geen dropdown meer verschijnen, maar een zoekvenster. (zie pmaWiki)

Er is wel een nadeel verbonden aan ‘display fields’. Ze worden namelijk niet geëxporteerd bij het nemen van backup van de database. Dit komt omdat de ‘display field’ een functie is van phpMyAdmin zelf, en niet van MySQL.

Null waarde als (deel van) primary key in MYSQL

Lijkt evident, maar is het niet: als je een samengestelde ‘primary key’ definieert in mySQL waarbij een van de delen van de primary key NULL-waarden kan bevatten en identieke rijen wil uitsluiten, kom je bedrogen uit.

Neem bijvooorbeeld volgende tabel waarbij je twee identieke rijen wil uitsluiten met behulp van de samengestelde primary key ‘user, e-mail, label’:

user	email	label
1	test@test.be	2
2	test2@test.be	NULL
2	test2@test.be	NULL

Rij 2 en 3 zijn voor jou als gebruiker identiek op het eerste zicht en zouden elkaar dus logisch uitsluiten. De database zou de derde rij niet mogen toelaten indien een samengestelde primary key is opgesteld over ‘user, email en label’, maar aangezien voor MySQL NULL waarden nooit identiek zijn, is dergelijk situatie perfect mogelijk in MySQL en moet je dus op zoek gaan naar een andere oplossing!

Verslag 100 km dodentocht Bornem 2009

Het is voor een tweede keer gelukt: de dodentocht tot een goed einde brengen. Ook dit jaar had ik weer hard aan de ‘ronsel’-bel getrokken en ik leek er nog goed in te slagen, maar tegen het einde vielen toch twee kameraden van het eerste uur af. Gelukkig ging Yves een tweede poging wagen en Jimmy wou het toch ook eens proberen. Alledrie zonder voorbereiding, respect alom dus!

Continue reading “Verslag 100 km dodentocht Bornem 2009”