MYSQL ID beim eintragen eines datensatzes direkt abfragen?

[Pete]

Hi,

wie der tietel schon sagt wollte ich euch mal fragen ob es möglich ist die ID(Auto Incresment und Primary ) direkt nach dem eintragen in die datenbank (in der selben datei und ohne reload) abzufragen

[Matthias Apsel]

Om nah hoo pez nyeetz, Pete!

wie der tietel schon sagt wollte ich euch mal fragen ob es möglich ist die ID(Auto Incresment und Primary ) direkt nach dem eintragen in die datenbank (in der selben datei und ohne reload) abzufragen

Nein, denn das Eintragen erfolgt ja sicherlicht POST-Request, also wird die Seite schon mal neu geladen ;-)

Du könntest aber mit

if ($_POST)  
{  
  // Daten eintragen  
  $akt_id = mysql_result(mysql_query("SELECT MAX(id) FROM table WHERE /*aktuellen Benutzer abfragen*/"),0)  
}

den Datensatz, den der aktuelle Benutzer gerade geschrieben hat, abfragen.

Matthias

[Pete]

danke für die schnelle antwort.
ich meinte natürlich nachdem der post gesendet wurde.

$sql = "INSERT INTO online(  
name,  
age,  
sex,  
psex,  
status)  
         VALUES(  
'".mysql_real_escape_string(trim($_POST['nickname']))."',  
'".mysql_real_escape_string(trim($_POST['age']))."',  
'".mysql_real_escape_string(trim($_POST['sex']))."',  
'".mysql_real_escape_string(trim($_POST['psex']))."',  
'".mysql_real_escape_string(trim($_POST['status']))."'  
";  
  
mysql_query($sql) OR die("<pre>\n".$sql."</pre>\n".mysql_error());  
  
$sql9 = "SELECT  
				*  
		FROM  
				online  
		WHERE  
				name = '".$_POST['nickname']."'  
		  
		";  
$result9 = mysql_query($sql9) OR die("<pre>\n".$sql9."</pre>\n".mysql_error());  
while($row9 = mysql_fetch_assoc($result9)){  
	  
	$ses_id = $row9['id'];  
	  
	}

so hatte ich die datei geschrieben würde das so funktionieren? kann zurzeit leider nix uploaden.

Bei deiner möglichkeit müsste ich dan ja noch ein +1 hinzufügen oder?

[hotti]

hi,

den Datensatz, den der aktuelle Benutzer gerade geschrieben hat, abfragen.

Wenn der ganze Prozess atomar ist, funktioniert das auch. Ich würds aber trotzdem nicht so machen, siehe Antwort von Vinzenz, allgemein:

Wenn eine bestimmte Funktionalität von der DB-Engine gegeben ist, nutze diese vorrangig, das ist immer performanter und sicherer als irgendeine eigene Bastelei.

Hotti

[Tom]

Hello,

den Datensatz, den der aktuelle Benutzer gerade geschrieben hat, abfragen.

Wenn der ganze Prozess atomar ist, funktioniert das auch. Ich würds aber trotzdem nicht so machen, siehe Antwort von Vinzenz, allgemein:

Wollte ich eben auch gerade schreiben, aber: dieses Problem wird durch einen Unique-Index auf den Nickname eventuell abgefangen. Da passt kein weiteres Insert mehr dazwischen, das zu einem anderen Ergebnis führen würde, nur ein Update oder Delete.

> Wenn eine bestimmte Funktionalität von der DB-Engine gegeben ist, nutze diese vorrangig, das ist immer performanter und sicherer als irgendeine eigene Bastelei.

Der weitere Vortiel ist, dass ein "Select Last_Insert_Id()" gar nicht auf die Tabelle, sondern nur auf den Transferbuffer für die Verbindung geht, also viel Kraft spart.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

hi Tom,

Wollte ich eben auch gerade schreiben, aber: dieses Problem wird durch einen Unique-Index auf den Nickname eventuell abgefangen. Da passt kein weiteres Insert mehr dazwischen, das zu einem anderen Ergebnis führen würde, nur ein Update oder Delete.

Oder: Ignore ;)

Auf jeden Fall: Schlüssel sinnvoll einsetzen, Recht haste ;)

Wenn eine bestimmte Funktionalität von der DB-Engine gegeben ist, nutze diese vorrangig, das ist immer performanter und sicherer als irgendeine eigene Bastelei.

Der weitere Vortiel ist, dass ein "Select Last_Insert_Id()" gar nicht auf die Tabelle, sondern nur auf den Transferbuffer für die Verbindung geht, also viel Kraft spart.

Das kann sehr schnell zum Nachteil werden, wenn _eine_ Verbindung von _mehreren Prozessen benutzt wird, alles schon in Aktion gesehen ;)

Hotti

[Tom]

Hello,

Der weitere Vorteil ist, dass ein "Select Last_Insert_Id()" gar nicht auf die Tabelle, sondern nur auf den Transferbuffer für die Verbindung geht, also viel Kraft spart.

Das kann sehr schnell zum Nachteil werden, wenn _eine_ Verbindung von _mehreren Prozessen benutzt wird, alles schon in Aktion gesehen ;)

Wie geht das? Wie kann ich eine Connection von mehreren Prozessen gleichzeitig nutzen?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

hi Tom;

Das kann sehr schnell zum Nachteil werden, wenn _eine_ Verbindung von _mehreren Prozessen benutzt wird, alles schon in Aktion gesehen ;)

Wie geht das? Wie kann ich eine Connection von mehreren Prozessen gleichzeitig nutzen?

Z.B. eine persistente DB-Connection über mod_perl (Webserver). Das lässt sich sogar noch steigern über globale DB-Handles aus des Sicht der Programmiersprache. Und so richtg bekloppt wird das, wenn diejenigen, die sowas machen, sich als Profis und die Art der Programmierung als objektorientiert bezeichnen ;)

Viele Grüße,
Hotti (Schreinerlaie und Legehennenexperte)

PS: Wo werden eigentlich Särge gebaut?

[Tom]

Hello Hotti,

Das kann sehr schnell zum Nachteil werden, wenn _eine_ Verbindung von _mehreren Prozessen benutzt wird, alles schon in Aktion gesehen ;)

Wie geht das? Wie kann ich eine Connection von mehreren Prozessen gleichzeitig nutzen?

Z.B. eine persistente DB-Connection über mod_perl (Webserver).

Das bedeutet also, dass das mod_perl die Verbindung aufbaut und hält? Wenn jetzt ein Request eintrifft, der durch das mod_perl zu bedienen ist, wird das Script doch aber erst zuende abgearbeitet, bevor das nächste in Angriff genommen wird, oder?

Üblicherweise stellt der Webserver einen Kindprozess pro Request und der erzeugt dann eine Instanz des Perl- oder PHP-Codes.

Wer hält denn nun die Datenbankverbindung?

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[hotti]

hi Tom,

Das bedeutet also, dass das mod_perl die Verbindung aufbaut und hält? Wenn jetzt ein Request eintrifft, der durch das mod_perl zu bedienen ist, wird das Script doch aber erst zuende abgearbeitet, bevor das nächste in Angriff genommen wird, oder?

Unabhängig von einer DB-Verbindung (vereinfacht ausgedrückt): Bei mod_perl wird ein sog. ResponseHandler (Perl) zusammen mit dem Webserver gestartet und diesen Handler teilen sich mehrere Prozesse.

Somit ist der Perl-Interpreter selbst bereits am Laufen. Der ResponseHandler wiederum kann eine persistente DB-Verbindung bereitstellen, die dann auch geteilt werden kann.

Üblicherweise stellt der Webserver einen Kindprozess pro Request und der erzeugt dann eine Instanz des Perl- oder PHP-Codes.

PHP: Die Datei wird geparst, wenn <?php CODE ?> drin ist, wird der ausgeführt.

Perl: Wenn eine CGI-Schnittstelle konfiguriert ist, wird die Datei ausgeführt über den Perl-Interpreter. Dazu wird alles was an Code-Sourcen per use, require eingebunden ist und die Code-Sourcen vom Script kompiliert. Ein solcher Overhead ist der Killer bei großen Frameworks in denen viele Sourcen für jeden Request neu kompiliert werden müssen.

Linderung schafft der AutoLoader: Code-Sourcen werden erst kompiliert, wenn die entsprechenden Methoden/Funktionen aufgerufen werden, tatsächlich ists ja so, dass nicht ALLE Funktionen in JEDER Response gebraucht werden.

Neben der Möglichkeit AL einzusetzen, beschreite ich in meinem Framewwork einen völlig anderen Weg, der mit wenig Overhead einen reinen CGI-Betrieb ermöglicht, wobei jede Datei, die text/html ausliefert, Perl-Code enthalten kann ohne selbst eine ausführbare Datei zu sein. Näheres siehe Link, weiter unten findest Du auch einen PAP (Struktogramme mag ich nicht) ;)

Wobei: Mein FW habe ich auch unter mod_perl mit dem Template::Toolkit getestet, das geht ab wie ein geölter Blitz ;)

Hotti

[hotti]

mod_perl:

Somit ist der Perl-Interpreter selbst bereits am Laufen.

Besser ausgedrückt: Der komplette Code des ResponseHandlers liegt kompiliert im Hauptspeicher.

D.h., dass bei einem Request kein neuer Code kompiliert werden muss oder nur sehr wenig. DB-Prozessen, die sessionbezogen sind (z.b. last_insert_id abfragen) würde ich einfach eine neue/eigene Connection geben und gut isses.

Reiner CGI-Betrieb: Jeder Prozess hat eine eigene DB-Session.

Hotti

[Matthias Apsel]

Om nah hoo pez nyeetz, Tom!

den Datensatz, den der aktuelle Benutzer gerade geschrieben hat, abfragen.

Wenn der ganze Prozess atomar ist, funktioniert das auch. Ich würds aber trotzdem nicht so machen, siehe Antwort von Vinzenz, allgemein:

habe ich verstanden.

Meine Antwort passt ohnehin nicht auf (das später angegebene) Vorhaben. Ich bin davon ausgegangen, dass es mindestens 2 Tabellen gibt, etwa Nutzer und Daten zwischen denen eine 1:n - Beziehung besteht.

Matthias

[hotti]

hi,

wie der tietel schon sagt wollte ich euch mal fragen ob es möglich ist die ID(Auto Incresment und Primary ) direkt nach dem eintragen in die datenbank (in der selben datei und ohne reload) abzufragen

Ein SELECT LAST_INSERT_ID(); liefert Dir nach dem Insert den zuletzt vergebenen auf die DB-Session bezogenen Wert für auto_increment.

Hotti

[Vinzenz Mai]

Hallo,

wie der tietel schon sagt wollte ich euch mal fragen ob es möglich ist die ID(Auto Incresment und Primary ) direkt nach dem eintragen in die datenbank (in der selben datei und ohne reload) abzufragen

ja, selbstverständlich:

mit PHP z.B. über
a) Erweiterung MySQL: mysql_insert_id()
b) Erweiterung MySQLi: mysqli_insert_id()
c) PDO: lastInsertId

mit SQL:
d) Funktion LAST_INSERT_ID()

Matthias' Vorschlag ist in Mehrbenutzerumgebungen (wie sie im Internet üblich sind) keine gute Idee, da der zurückgelieferte Wert nicht der gewünschte sein muss, was die von mir genannten bei Verwendung in der gleichen Verbindung garantieren.

Freundliche Grüße

Vinzenz

[Matthias Apsel]

Om nah hoo pez nyeetz, Vinzenz Mai!

Matthias' Vorschlag ist in Mehrbenutzerumgebungen (wie sie im Internet üblich sind) keine gute Idee, da der zurückgelieferte Wert nicht der gewünschte sein muss,

Nur wenn dieselbe Person mehrfach angemeldet ist.

Matthias

[Vinzenz Mai]

Hallo Matthias,

Matthias' Vorschlag ist in Mehrbenutzerumgebungen (wie sie im Internet üblich sind) keine gute Idee, da der zurückgelieferte Wert nicht der gewünschte sein muss,

Nur wenn dieselbe Person mehrfach angemeldet ist.

Zum Beispiel. Oder ...

Der von Dir vorgestellte Vorschlag ist keine gute Idee. Man verwendet die passende Funktionalität, die die API des Datenbankmanagementsystems bietet, wie von mir für die Kombination von PHP und MySQL aufgelistet.

Freundliche Grüße

Vinzenz

[Tom]

Hello Matthias,

Matthias' Vorschlag ist in Mehrbenutzerumgebungen (wie sie im Internet üblich sind) keine gute Idee, da der zurückgelieferte Wert nicht der gewünschte sein muss,

Nur wenn dieselbe Person mehrfach angemeldet ist.

Und wenn der Datensatz für name einen unique Index hat, die Person sich also unter demselben Namen nur einmal anmelden kann, dann benötugt man auch kein max(). Dann gibt es den Datensatz ja nur einmal und die id ist eigentlich eine redundante Information, denn sie ist ja als autoincrement primary auch eineindeutig.

Dann ist also eigentlich das Datenmodell überbestimmt :-)

Das kann aber auch richtig sein, wenn man z.B. den Namen änderbar halten will.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg