Veröffentlicht 7. März 200520 j hallo, wie eindeutig ist diese uniquid()? kann ich die als primärschlüssel für datenbankentabellen verwenden? ein auto_increment bietet sich leider nicht an! Da ich sonst die letzte eingefügte id mit mysql_insert_id() auslesen müsste und in der zwischenzeit kann ja schon wieder was eingefügt worden sein. Oder kennt jemand alternativen
7. März 200520 j Du kannst auch Datenbankseitig mit der "last inser id" arbeiten: INSERT INTO foo2 (id,text) VALUES(LAST_INSERT_ID(),'text'); Gruß, Markus
7. März 200520 j hallo, wie eindeutig ist diese uniquid()? kann ich die als primärschlüssel für datenbankentabellen verwenden? ein auto_increment bietet sich leider nicht an! Da ich sonst die letzte eingefügte id mit mysql_insert_id() auslesen müsste und in der zwischenzeit kann ja schon wieder was eingefügt worden sein. Oder kennt jemand alternativen Also bei mir funtzt das mit auto increment wunder bar du läst halt beim insert die id weg und MY SQL errzeugt selbst eine
7. März 200520 j also auto increment geht bei mir auch. Aber dann weiß ich halt nicht beim einfügen, welche id jetzt vergeben worden ist. Aber diese brauche ich gleich darauf für die nächste insert anweisung. Wenn ich die dann mit last_insert_id() -oder so änlich- auslese kann ich doch probleme bekommen, wenn in der zwischenzeit andere daten in die datenbank geschrieben worden sind. Da hab ich dann ziemlichen durcheinandern in den tabellen.....oder lieg ich da falsch?
8. März 200520 j also auto increment geht bei mir auch. Aber dann weiß ich halt nicht beim einfügen, welche id jetzt vergeben worden ist. Aber diese brauche ich gleich darauf für die nächste insert anweisung. Wenn ich die dann mit last_insert_id() -oder so änlich- auslese kann ich doch probleme bekommen, wenn in der zwischenzeit andere daten in die datenbank geschrieben worden sind. Da hab ich dann ziemlichen durcheinandern in den tabellen.....oder lieg ich da falsch? AFAIK ist das ganze Thread-safe.... Gruß, Markus
8. März 200520 j Die letzte erzeugte Kennung wird im Server auf der Grundlage der jeweiligen Verbindung gewartet. Sie wird nicht durch andere Clients geändert. Sie wird nicht einmal geändert, wenn Sie eine andere AUTO_INCREMENT-Spalte mit einem nicht magischen Wert aktualisieren (einem Wert, der nicht NULL und nicht 0 ist). quelle: http://dev.mysql.com/doc/mysql/de/getting-unique-id.html Kann ich es jetzt so machen oder nicht? Denn bei mir ist ja der client immer der gleiche (der php server), da nicht die clients im internet direkt auf den mysql server zugreifen.
8. März 200520 j quelle: http://dev.mysql.com/doc/mysql/de/getting-unique-id.html Kann ich es jetzt so machen oder nicht? Denn bei mir ist ja der client immer der gleiche (der php server), da nicht die clients im internet direkt auf den mysql server zugreifen. Aber jede instanz die von PHP läuft hat einer andere Verbindungskennung und somit kannst du die mysql_insert_id() verwenden... Gruß, Markus
11. März 200520 j Aber jede instanz die von PHP läuft hat einer andere Verbindungskennung Aha, die Verbindungskennung ist doch $db = mysql_connect($dbserver,$nutzer,$passwort) OR die($dbfehler1); Sollte ich die dann bei mysql_query() unbedingt angeben, oder? Da ja sonst doch der besagte Fehler auftreten könnte. Wenn man sie weg lässt, wird ja die zuletzt geöffnete verbindungskennung verwendet (im schlechtesten falls ist das dann nicht die vom eigenen php-skript?)
11. März 200520 j Aha, die Verbindungskennung ist doch $db = mysql_connect($dbserver,$nutzer,$passwort) OR die($dbfehler1); Sollte ich die dann bei mysql_query() unbedingt angeben, oder? Da ja sonst doch der besagte Fehler auftreten könnte. Wenn man sie weg lässt, wird ja die zuletzt geöffnete verbindungskennung verwendet (im schlechtesten falls ist das dann nicht die vom eigenen php-skript?) du musst die verbindungskennung von mysql_connect() bei mysql_query() nur dann angeben, wenn du innerhalb des scripts mehr als eine Verbindung öffnest. Im normallfall reicht eine Verbindung, deshalb könnte man es weg lassen. Gruß, Markus
11. März 200520 j hmm, ich bin mir einfach nicht sicher ob das im "worst case" nicht schief geht. ....stellen Sie sicher, dass Sie mysql_insert_id() direkt nach der Abfrage aufrufen, die einen Wert erzeugt hat. Kann ich das sicherstellen wenn viele viele leute das skript gleichzeitig ausführen?
11. März 200520 j AFAIK ja, sonst würde viele Seiten auf denen am Tag 100000 Zugriffe stattfinden riesen Probleme haben....
11. März 200520 j ok, ich werd das mal im Hinterkopf behalten. Die mögliche Alternative: Ich lasse von php eine zufällige ID generieren (uniqid). Wie sicher kann ich sein, dass da wieder nicht 2 gleichzeitig das script aufrufen? Das ganze ist halt mein abschlussprojekt und ich möchte mir da keine Fallstricke diesbezüglich bauen...
11. März 200520 j Die mögliche Alternative: Ich lasse von php eine zufällige ID generieren (uniqid). Wie sicher kann ich sein, dass da wieder nicht 2 gleichzeitig das script aufrufen? Ich würde destotrotz das PHP intern regeln lassen. Einfach mal ein bisschen vertrauen....
11. März 200520 j Die mysql_insert_id() speichert die ID des Statements, welches zuletzt in diesem Script ausgeführt wurde (so habe ich es zumindest bis jetzt immer verstanden), Ich verstehe dein Problem. Aber die letzte Insert-Anweisung gibt die ID quasi an das Script. Damit kannst hast du sicher immer die zuletzt eingefügte ID zum weiterarbeiten. Es ist nicht möglich, dass dadurch dass ein anderer Kunde in der Zwischenzeit einen Datensatz einfügt deine Referenzen verschoben werden! gruss markus
11. März 200520 j Einfach mal ein bisschen vertrauen.. das kann ich schon machen.... :hells: solange mir der Prüfungsausschuss kein Bein dabei stellt... Bei Fragen gebe ich einfach kills und Krain als Referenz an
12. März 200520 j solange mir der Prüfungsausschuss kein Bein dabei stellt... Bei Fragen gebe ich einfach kills und Krain als Referenz an eben... sag einfach das das von PHP intern alles behandelt wird und mann sich deshalb keine sorgen machen muss... mit verweis auf die link von oben Gruß, Markus
Archiv
Dieses Thema wurde archiviert und kann nicht mehr beantwortet werden.