Problem bei AUTO_INCREMENT

[Xot]

Hallo zusammen...

ich habe folgenden Code der den AUTO_INCREMENT Wert ab einer bestimmten Stelle zurücksetzen soll:

$id = mysql_insert_id();
echo $id;
echo '<br>';
echo '1000000000';
echo '<br>';
if ($id > 1000000000) {
  echo "test";
  mysql_query("ALTER TABLE captcha AUTO_INCREMENT=1");
  echo mysql_error();
}

Die Ausgabe ist folgendes:
1000000038
1000000000
test

Also keine Fehler oder sonstiges! Jedoch wird der AUTO_INCREMENT nicht wieder auf 1 gesetzt. Jemand ne Ahnung wieso?

Edit: Wenn ich den Code direkt in PHPMyAdmin ausführe klappts!

 

[Sebmaster]

Wenn du bereits eine Zahl > der zu setzende Wert drin hast, kann das nicht funktionieren, weil dann ja irgendwann eine ID öfter vorkommen wird

 

[theHacker]

Einfach Tabelle leerlöschen, dann klappts auch mit der Manipulation des Auto-Increment-Zählers. TRUNCATE nimmt dir die Arbeit ab

 

[Xot]

TRUNCATE

Danke euch beiden. Hat geklappt.

 

[WhiZZler]

also entweder du hast dein problem extrem schlecht beschrieben oder dir ist nicht bewusst, dass du die tabelle mit TRUNCATE leerst

mich hat dieser thread so früh am morgen allerdings amüsiert!

 

[Xot]

Das ist mir schon klar das ich die Tabelle mit TRUNCATE leere...

Ich habe eine Tabelle mit ID, Captcha Werten, IP und der Zeit. Bei jedem Aufruf wird ein neuer Eintrag in der Datenbank erstellt. Nun könnte es mal sein, dass die ID den maximalen Wert erreicht (ID ist ein Int Feld). In diesem Falle möchte ich das der Auto_Increment wieder bei 1 anfängt.

Da man den Wert laut Sebmaster aber nicht ändern kann wenn ein grösserer Wert drinnen ist, lösche ich mit TRUNCATE die Tabelle und schreibe die noch benötigten Einträge wieder in die Tabelle.

 

[marac]

Mal völlig unabhängig von der Lösung: Brauchst du das wirklich? Selbst wenn du jede Sekunde einen Eintrag in dieser Tabelle erzeugen würdest, würde das Feld bei einem vorzeichenbehafteten 32-Bit-Integer erst in rund 68 Jahren überlaufen...

 

[Xot]

Mal völlig unabhängig von der Lösung: Brauchst du das wirklich?

Da bin ich mir selber nicht sicher ob diese Grenze jemals erreichen wird...
Doch ich tu diese Möglichkeit lieber im vorhinein ausschliessen, als das ich später damit Probleme bekomme.

 

[tobias1985]

Lies mal etwas bezüglich unsigned nach. Außerdem gibt es auch noch sowas wie bigint. Wenn das alles nicht reicht, weiß ich auch nicht.
Und frag dich mal, ob du die ID in der Tabelle überhaupt brauchst. Kommt mir so vor, als ob du dir die ID auch sparen könntest.

 

[Xot]

Lies mal etwas bezüglich unsigned nach. Außerdem gibt es auch noch sowas wie bigint. Wenn das alles nicht reicht, weiß ich auch nicht.
Und frag dich mal, ob du die ID in der Tabelle überhaupt brauchst. Kommt mir so vor, als ob du dir die ID auch sparen könntest.

Die Spalte ist bereits unsigned...
BigInt möcht ich nicht nehmen, da dies doppelt so viel Speicherplatz benötigt und die Tabelle sehr gross wird... Da bleibe ich lieber bei der jetzigen Möglichkeit und lösche nicht benutzte Einträge mit der Zeit.

 

[ice-breaker]

Da bin ich mir selber nicht sicher ob diese Grenze jemals erreichen wird...
Doch ich tu diese Möglichkeit lieber im vorhinein ausschliessen, als das ich später damit Probleme bekomme.

äh ja, ich miete mir auch erst eine Garage, schließe eine Versicherung ab, kaufe mir neue Winterreifen bevor ich mir ein Auto zulege...

Dies ist ein klassisches Problem von premature optimization, du willst einen Sachverhalt optimieren, der dich momentan nicht interessiert und den du auch ziemlich sicher nie erreichen wirst, und selbst wenn, kann man sich dann da noch früh genug darüber Gedanken machen.

 

[marac]

Die Spalte ist bereits unsigned...

Dann sind wir ja schon bei 136 Jahren (bei einem Eintrag pro Sekunde)...

 

[TerraTux]

Das kann man doch auch sparsamer hinbekommen. Wie oben schon geschrieben wird die ID gar nicht benötigt.

Wenn eine Captcha angezeigt werden soll, wird ein Eintrag mit Code, und einem aus Zeit, IP und Trallalla generiertem Hash in der Tabelle gemacht. Beim Absenden des mit der Captcha gesicherten Formulars wird der Hash (anstelle der ID) mit übertragen und bei der Auswertung des Forms zusammen mit dem Captcha-Code ausgewertet.
Sobald während dieser Auswertung mal "TRUE" oder "FALSE" für die Captcha hast, löschst Du den Eintrag wieder aus der Tabelle. Den Hash solltest Du an dieser Stelle ja noch haben und kannst an hand dieser löschen.

nur ein Vorschlag

Gruß

 

[ice-breaker]

ist aber noch nicht ausgereift
Ein Hash wird definitiv deutlich mehr Speicherplatz belegen als eine Id, ob auch mehr als Id+Captcha-Wert weiß nur der Thread Starter.

Und wie löschst du in deinem System veraltete Captchas, die nicht getippt wurden?
Man braucht also noch einen Zeitstempel

 

[TerraTux]

ist aber noch nicht ausgereift
Ein Hash wird definitiv deutlich mehr Speicherplatz belegen als eine Id, ob auch mehr als Id+Captcha-Wert weiß nur der Thread Starter.

Macht ja nix, werden doch wieder gelöscht, und nicht für Jahrzehnte aufgehoben

Und wie löschst du in deinem System veraltete Captchas, die nicht getippt wurden?

Natürlich, wie Du schon sagst, mit Zeitstempel und einem Timeout. Aber es ging mir im Grunde nur um einen anderen Ansatz, anstelle der fortlaufenden ID...

Gruß