Nieuwe tabel maken en InnoDB
Ik maak t.b.v. mijn site regelmatig nieuwe tabellen aan. Dit gaat zonder problemen. Wat mij echter opvalt is dat sinds enige tijd phpMyAdmin een andere, nieuwe opslagengine toont. Tegenwoordig is dit InnoDB terwijl voorheen gebruik gemaakt werd van myISAM.
Mijn vraag zijn nu:
1. Wat is het verschil tussen beide instellingen,
2. Kan ik beide engines door elkaar gebruiken
George
bv. met InnoDB kan je foreign key's zetten;
Je kan bv ook dit doen:
Code (php)
1
2
3
4
2
3
4
PRIMARY KEY(page_id),
FOREIGN KEY(section_idfk) REFERENCES sections(section_id)
ON DELETE CASCADE
ON UPDATE CASCADE
FOREIGN KEY(section_idfk) REFERENCES sections(section_id)
ON DELETE CASCADE
ON UPDATE CASCADE
Dus, daarmee stel je je tabel in zodat ze de connectie blijft leggen.
Voorbeeld: je hebt een tabel 'users', en een tabel 'messags' (een shout box, of gastenboek of zo)
Tabel messages bevat een veld 'author', waarin je de username zet.
Dus zowel in users als in messages staat bv. de wa&arde 'Tom'.
Als Tom zijn profiel wijzigt, en nu 'Tommeke' heet, wordt de waarde Tom ook aangepast naar Tommeke in de tabel messages.
Als Tom zijn account verwijdert, worden ook alle messages met user="Tom" verwijderd.
Meer (alle?) engines staan op wikipedia, maar met minder uitleg: http://en.wikipedia.org/wiki/Comparison_of_MySQL_database_engines
Kris Peeters op 23/09/2013 11:03:39:
Een relatie als deze is overigens niet aan te bevelen. Leg de relaties bij voorkeur altijd op ID zoals in het voorbeeld, id en idfk. De wijziging van Tom naar Tommeke hoeft dan alleen maar in het profiel plaats te vinden en niet in de child-records.InnoDB biedt een aantal extra's. Als Tom zijn profiel wijzigt, en nu 'Tommeke' heet, wordt de waarde Tom ook aangepast naar Tommeke in de tabel messages.
Als Tom zijn account verwijdert, worden ook alle messages met user="Tom" verwijderd
Als Tom zijn account verwijdert, worden ook alle messages met user="Tom" verwijderd
Dit is er toch speciaal voor gemaakt?
Okay, stel, een clean name (geen speciale tekens; spaties vervangen door _ ), iets wat zonder probleem in een URL kan ...
Waarom zou je die relatie niet daarmee zetten?
(Niet dat ik je ongelijk geef, hoor, maar je maakt je er wat gemakkelijk van af)
Kris Peeters op 23/09/2013 11:28:11:
Het is niet gemaakt om een string honderden malen te herhalen. Het is gegevenstechnisch onzin om de naam Tommy of Tommeke honderden malen op te slaan, dit gegeven hoort thuis in de bovenste entiteit. De foreign key relatie is gemaakt voor gegevens integriteit (parent-child) en om dat efficient te gebruiken moet je dat altijd doen op ID's en niet op gegevens die je dan onnodig gaat herhalen zoals Tom, Tommy, Tommeke etc. Wanneer Tom honderden messages heeft en hij past tom aan naar Tommeke zou dat in het voorbeeld geval een update van honderden keren Tom naar Tommeke worden. Absoluut fout qua gegevensverwerking en datamodellering.Waarom zou je dit niet aanraden?
Dit is er toch speciaal voor gemaakt?
Dit is er toch speciaal voor gemaakt?
Gewijzigd op 23/09/2013 12:16:45 door John D
De dingen die je aanhaalt, maken dan weinig uit.
Kris Peeters op 23/09/2013 12:28:04:
Correct, wanneer je de key en de foreign key's koppelt op ID is een cascade update overbodig maar nogmaals, altijd op id werken en niet op tommy. Nooit gegevens herhalen.Akkoord dat "ON DELETE CASCADE" zinniger is dan "ON UPDATE CASCADE"?
De dingen die je aanhaalt, maken dan weinig uit.
De dingen die je aanhaalt, maken dan weinig uit.