Hey,
ich stelle mir schon seit ein paar Tagen dieselbe Frage, jetzt poste ich einfach mal.
In der Datenbank werden ja die IDs gespeichert. Angenommen dort habe ich nur INT eingestellt.
Was passiert, wenn es mehr als diese bisschen mehr als 2 Mrd. IDs gibt, gehts dann wieder von vorne los, oder wie? Kann ja eigentlich nicht sein...
Würde mich mal rein theorethisch interessieren.
MfG, D4rk5inSofern kein freier Platz mehr ist, wird dein INSERT (bzw. UPDATE) nicht erfolgreich und mit einem Fehler quittiert.
Okay, danke!
bei unsingned sind es schon mal 4 mrd
davon abgesehen dass du diese zahl mit deiner anwendung wohl kaum jemals erreichen wirst, kannst auch long/bigint nehmen
Einen INT-Wert kann man schon relativ schnell erreichen...
Nehmen wir mal ein großes Communityportal oder großes Browsergame und nehmen an, dass 50.000 aktive User jeden Tag im Durchschnitt z.B. 10 Gästebucheinträge (oder im Browsergame 10 Nachrichten oder sowas) schreiben.
Dann wäre nach 12 Jahren bereits mit INT Schluss...
//EDIT: Btw: Ich kann doch via PHP mit Hilfe von (int) eine Variable in Integer umwandeln. Gibst so eine Funktion auch für z.B. Bigint? Gefunden hab ich bisher nichts...
nach 12 jahren wird das game in der urprünglichen form vermutlich keiner mehr spielen oder sich nicht man daran erinnern, also ist kein gutes argument, von der server/dblast bei dem useraufkommen will ich garnicht reden
Auch wenn das Problem von manchen Kleingeister als sehr irreales Problem dargestellt wird, so bleibt das Problem der ausgehenden auto_increment werte doch ein sehr reales. Deswegen sollte man nun nicht unbedingt alles gleich auf BigInt auslegen, sondern eher zum einen etwas überlegen was man mit welcher Tabelle machen will und das auch über die Zeit bedenken und zum anderen die vorhanden Möglichkeiten des Monitorings überdenken. Ein Monitoring das die verbliebenen Ids überwacht schadet nie und kann einem bei fehlenden oder falschen Überlegungen rechtzeitig warnen.
Die meisten auto_increment ids werden ein int signed (auch wenns kein sinn macht) und nicht unsigned sein (wer unsigned setzt hat schonmal kurz darüber nachgedacht).
Bleiben uns also 2.1 Mrd ids.
Beispiel 1) Rundenlänge 1 Jahr, 25k User
Nehmen wir eine populäre logtabelle her. 2.1Mrd/365 Tage/ 25k User bist du schon bei geradeeinmal 230 Einträge/User/Tag . Nun besteht eine Aktion meist aus mehreren Teilaktionen sagen wir nun 3 Teilaktionen. Nehmen wir einen Angriff so ist das z.B. 1) Truppen losschicken 2) Kampf berechnen 3) Truppen mit beute heimkehren. Oder im Postgame wären das z.B. mind. 3: 1) Bestellung erstellen 2) Bestellung wegschicken 3. - n-1) Bestellung weiterleiten n) Bestellung beantworten.
230/3 = sind schon wieder nurnoch 76 Aktionen pro User pro Tag. Unschaffbar für die User?
Viele werden natürlich ihre Logtabellen kleiner halten indem sie nur die letzten x Tage in einem so detailierten Log speichern, aber das ändert natürlich nichts an der Problematik der ausgehenden ids.
Beispiel 2) sowas wie pennergame: Ich spar mir die Rechnung und verweise nur auf ihre eigene Statistik:
Anzahl der Flaschen: 131674817608 = 131 Mrd
Anzahl der verkauften Flaschen: 536422988676 = 536 Mrd
Wertebreich des unsigned ints?
Kommen wir zurück zu meinem uralten Anliegen freigegebene IDs wiederzuverwenden.
Nehmen wir doch mal ein ganz extremes Beispiel: Twitter. Da entstehen sekündlich zig Einträge, dort sind die Grenzen schneller erreicht als du "int" sagen kannst ;)
Habe gehört, dass sie aus diesem Grund stattdessen einen String verwenden - der läuft nicht so schnell über. Allerdings wandeln viele Twitter-Clients das wieder in ints um und ... naja: http://www.twitpocalypse.com/ ;)
Das ist allerdings ein Extremfall und sollte für BGs nicht relevant sein. Wer ganz paranoid ist, greift auf Klaus' Vorschlag zurück, lösche alte Datensätze und füllt die Lücken auf.
Stichwort: GUID. Sollte das von vorne herein klar sein, dass es Probleme mit zu vielen Datensätzen gibt, kann man auch solche IDs verwenden. Die werden generisch/zufällig erzeugt und sind so extrem vielfältig, dass die Wahrscheinlichkeit des Konfliktes gering genug ist (müsste eine neue GUID generiert werden). In manchen Programmiersprachen/-frameworks sind entsprechene Generatoren schon drin, von CakePHP weiß ich, dass es sogar im Model neben Autoincrement als "Typ" unterstützt wird.
Die Lauf- und Zugriffszeit ist gar nicht mal so das Problem; der Index über gängigerweise 16 Byte wird entsprechend indiziert, das macht die Datenbank schon..
Edit: Die Tante Wiki sagt: http://de.wikipedia.org/wiki/GUID
Original von knalli
Stichwort: GUID.
GUIDs haben noch den Vorteil, dass z.B. wenn es der Browsergameaufbau hergibt mehrere Welten einfach zusammenführen kann.