PDO transaction prepared statements

Door Mich op 23-04-2014 13:33

4.387 views

Allen,

Op de bekende zoekmachine kom ik genoeg voorbeelden tegen van prepared statements i.c.m. transactions.
Maar toch werkt bij mij de rollback niet. Een exception op de 2e tabel, terwijl de 1e wel is toegevoegd.

Kan iemand mij uitleggen wat er fout gaat? Dit is de eerste keer dat ik transactions wil gebruiken.

Ingekort voorbeeld:


<?php
try
{
	$db->beginTransaction();

	$sql = "
	INSERT
		INTO " . TABLE_PREFIX . "profile
		(
			naam
		)
		VALUES
		(
			:naam
		)
	";
	
	$stmt = $db->prepare($sql);
	
	$stmt->bindParam(':naam', $_POST['gegevens']['naam'], PDO::PARAM_STR);

	$stmt->execute();
	
	$profile_id = $db->lastInsertId();
	
	$sql = "
	INSERT
		INTO " . TABLE_PREFIX . "application
		(
			profile_id
		)
		VALUES
		(
			:profile_id
		)
	";
	
	$stmt = $db->prepare($sql);
	
	$stmt->bindParam(':profile_id', $profile_id, PDO::PARAM_INT);

	$stmt->execute();
	
	$db->commit();
}
catch(PDOException $e)
{
	if(isset($db))
	{
		$db->rollBack();
	}
}
?>

Bvd

Ward van der Put

24-04-2014 15:23

Ik analyseer de incomplete orderdata en gooi ze daarna weg. Soms duikt daar bijvoorbeeld opvallend vaak een bepaald product in op: dan weet je dat er iets schort aan de prijs of de omschrijving en los je het probleem op, maar de data heb je niet voor eeuwig nodig.

Met sitestatistieken doe ik dat ook: na circa 18 maanden zijn ze niets meer waard, omdat een site (en eigenlijk half internet) na anderhalf jaar te ingrijpend is veranderd. Jaar-op-jaar-verschillen zijn wel belangrijk, bijvoorbeeld bezoeken rond Koningsdag in april vorig jaar versus april dit jaar, maar daarna wordt het al gauw appels met peren vergelijken.

Eigenlijk zou je er een back-up van moeten maken, "want je weet maar nooit", maar statistisch gezien heb je er in de praktijk meestal niets aan.

Mich

24-04-2014 15:31

Heb je een scriptje gemaakt die je dan af en toe runt en waar dat soort opvallende dingen dan in naar boven komen? Dat heb je dan mooi gedaan en zeker nuttig.

Daar heb je eigenlijk helemaal gelijk in :) Vaak is de opslag van dat soort statistieken niet groot, dus dan is het meer van 'laat maar staan'.

Hoe zou jij het datamodel normaliseren?

Ward van der Put

24-04-2014 15:46

Verwijst profile_id naar één persoon? Dan zou ik het zo laten. Wel heb je dan inderdaad data die ook later nog kunnen worden toegevoegd, dus een transactie is niet per se nodig. Data kunnen zelfs worden uitgebreid: bijvoorbeeld werkervaring en opleiding kunnen na verloop van tijd veranderen.

Voor data-analyse gebruik ik Excel en soms gewoon MySQL. Bijvoorbeeld man/vrouw-verschillen vinden is een kwestie van een simpele GROUP BY.

Mich

24-04-2014 16:01

Ik heb even het installatie bestand in een pastebin gezet dan kun je zien hoe ik het heb toegevoegd.
profile_id is het uniek auto_increment id van de tabel 'profile'. Er kunnen nu dus in principe meerdere zelfde profielen worden toegevoegd met een eigen id.

Ward van der Put

24-04-2014 16:08

Als ik het goed zie, kun je doen met de andere tabellen wat je wilt, zolang je maar de juiste profile_id te pakken hebt. Dat lijkt me wel goed, want je hebt één duidelijke afhankelijkheid, maar die is meteen goed te hanteren.

Mich

24-04-2014 16:16

Top :) Dan is alleen nog het 'probleem' hoe ik goed de profile_id/last insert id te pakken krijg.

In jouw ene voorbeeld kon het dus niet (alles op één moment executen) en mijn manier (in de eerste post) is niet helemaal goed?

Is jouw tweede voorbeeld wel goed dan? De eerste executen om het id te krijgen, om vervolgens de rest voor te bereiden en als laatste 2 tm .. de executen. Of is dat nou niet meer van toepassing als we de rollback laten vervallen.

Ward van der Put

24-04-2014 16:40

Je kunt hier een beslissingsregel inbouwen: wat heb je minimaal nodig om iemand te kunnen toevoegen?

Die beslissingsregel bepaalt namelijk hoe je initiële transactie eruit ziet. Díé eerste "minimalistische" INSERTs moeten in hun geheel slagen of falen. Dit levert je de "minimale dataset" op met gegevens die je nodig hebt om de boel niet als een kaartenhuis te laten instorten.

Daarna kun je veel flexibeler op bepaalde onderdelen data toevoegen, zolang je maar de juiste ID bij de hand hebt. Dat kan eventueel ook dagen, weken, maanden later nog — wat jij nodig hebt.

Vergelijk het met het opbouwen van een profiel bij een sociaal netwerk, bijvoorbeeld LinkedIn of Google+. Je moet minimaal x, y en z opgeven voor een account. Maar daarna werken de meeste onderdelen ook goed met een profiel dat maar 60% of 85% compleet is. Je kunt het gebruikers dus ook uitleggen.

Waar je voor een specifieke applicatie nog een specifiek gegeven nodig hebt, stel je een vraag: "Voor dit ene moet je wel zus-en-zo nog instellen." En dat kan dan eventueel nog een INSERT ... ON DUPLICATE KEY UPDATE ... zijn als de bijbehorende tabel in eerste instantie leeg kan zijn.

Mich

25-04-2014 08:31

Nou ik wil in ieder geval dat minimaal de eerste insert goed is, 'profile', en de tweede, application.
Dit zijn o.a. de persoonsgegevens. Ze hoeven allebei niet 100% gevuld te zijn, maar wel het grote deel en die moeten slagen anders heeft de rest ook geen zin. De rest van de tabellen kan erg uiteen lopen dus dat is niet direct verplicht.

Je kunt het niet vergelijken met een profiel, maar ik snap je punt. In dit geval gaat het om een formulier zonder login o.i.d. Ik zit dus nu ook te denken of ik nog een random key moet toevoegen aan 'profile' waar ik op terug kan vallen om bijvoorbeeld een linkje te sturen waarin men het formulier kan aanpassen (Dat kan dan weer mooi met ON DUPLICATE UPDATE).

Reageren

Inloggen om te reageren