RootForum Community

Hi Leute,

ich hab ein Script, dass Members verwaltet, und jedem neuen Member eine 'id' zuweist, das Feld 'id' ist dabei 'auto_increment'.

Nun stelle man sich vor 10 User haben sich bisher registriert (also id 1 bis 10 belegt) und der User mit der id=5 möchte seinen Account löschen.

Dadurch entsteht im 'id' Feld eine Lücke, die der nächste Member, der sich registriert, bekommen soll.

Bisher hab ich es so, dass diese Abfrage von einer PHP Schleife übernommen wird, die bei id=1 beginnt und hochzählt, solange bis eine id nicht existiert.

Meine Frage ist nun, ob es eine optimalere Lösung gibt, denn wenn erst an der Stelle id=10000 eine Lücke ist, geht die Schleife ja von 1 bis 10000 bis sie was freies findet.

Weiss jemand was besseres? Evtl. gibt es dafür speziell ein MySQL Query?

Vielen Dank im Voraus für Antworten.

Grüße

Hi Du,

es ist die Aufgabe der Datenbank, sich um die korrekte Verteilung der ID´s zu kümmern.

http://www.dclp-faq.de/q/q-sql-ids.html

Gruß Gerd

was mich interessieren würde warum willst du die ids auffüllen??? ist doch völlig egal ob die id 5 da ist oder nicht???!!!!

also ich hätte einfach gerne eine lückenlose tabelle, nicht beispielsweise wie in meinem guestbook, dort habe ich auch eine fortlaufende ID mit smallint(6) und auto_increment

und nach einer gewissen Zeit, werden die Einträge die z.B. älter als 1 Monat sind, gelöscht, dadurch entstehen riesenlücken... die IDs der Einträge fangen dann zb bei 55555 an und hören bei 123456 auf, anstatt bei 0 anzufangen...

irgendwann ist es dann soweit, dass ich den Datentyp für das ID Feld höher setzen muss, zB auf mediumint oder integer, und das möchte ich nicht unbedingt... (versuche alles so klein wie möglich zu halten, auch wenn die einsparungen dabei gering sind)

jedenfalls hab ich viel nachgelesen, ich glaube eine andere Lösung als über ne Schleife gibts leider nicht ;|

Hi,

dann setzt du den Datentyp halt auf sowas wie unsigned int, das verbraucht pro Eintrag Tabellenzeile 2 Byte mehr als smallint und bietet ca. 4,3 Milliarden eindeutige Zahlen. Und im Notfall nimmst du halt 8bytiges BigInt, dann können sich sehr viele Leute eintragen. Da du zwischendurch Einträge löschst wird die Datenbank durch diesen Mini-Datentyp sicherlich nicht zu groß, da macht eine Zeile mehr Eintrag im Gästebuch viiiiel mehr aus.

Gruß,
Dominik

Hi,

m-dreamer wrote:und nach einer gewissen Zeit, werden die Einträge die z.B. älter als 1 Monat sind, gelöscht, dadurch entstehen riesenlücken... die IDs der Einträge fangen dann zb bei 55555 an und hören bei 123456 auf, anstatt bei 0 anzufangen...

irgendwann ist es dann soweit, dass ich den Datentyp für das ID Feld höher setzen muss, zB auf mediumint oder integer, und das möchte ich nicht unbedingt... (versuche alles so klein wie möglich zu halten, auch wenn die einsparungen dabei gering sind)

wenn Du einen Datensatz löscht, wird die ID von der Datenbank wieder neu vergeben, sobalt der Wert überläuft ...
Es ist also nicht nötig, den Datentyp zu vergrößern. Ein unsigned smallint bietet 65535 möglich Datensätze (ID´s), auch wenn die größt mögliche ID vergeben ist.
Im übrigen sollte eine auto_increment Spalte immer das Attribut unsigned erhalten.
Also ich finde es relativ sinnfrei, keine Lücken in den ID´s zu haben. Es geht hier ja um die richtige Zuordnung von Datensätzen und nicht um die Reihenfolge der ID´s.


Gruß Gerd

hAhNeBueChEn wrote:Hi,
wenn Du einen Datensatz löscht, wird die ID von der Datenbank wieder neu vergeben, sobalt der Wert überläuft ...

Genau deswegen sollte man IMHO den Int-Typ auch groß genug wählen. Für ein Gästebuch nicht weiter tragisch, bei Userverwaltungen oder ähnlichem kann es aber zu Problemen kommen, wenn nach einiger Zeit ein neuer User mit einer schon einmal belegt gewesenen ID erstellt wird.

Daher: Nicht an der falschen Stelle sparen, bei einem Gästebuch kommt es auf die zwei Bytes pro Eintrag sicher nicht an.

Gruß,
Dominik

SunTzu wrote:Für ein Gästebuch nicht weiter tragisch, bei Userverwaltungen oder ähnlichem kann es aber zu Problemen kommen, wenn nach einiger Zeit ein neuer User mit einer schon einmal belegt gewesenen ID erstellt wird.

also eine gut geplante Datenbank, sollte eine ID immer genau zuordnen können. Wird Sie in einer Tabelle gelöscht, muß Sie natürlich auch überall anders gelöscht werden.
Wird z.B. ein User eines Forums gelöscht, sollten auch alle seine Beiträge gelöscht werden, ansonsten wäre es doof den User zu löschen ...
Hat man Ordnung im System, spricht meiner Erfahrung nach nichts dagegen, die ID wieder neu zu vergeben.

Gruß Gerd

bevor du 5000 mal deine DB fragst ob die ID frei ist kannst du auch en neue Tabelle erstellen in der du die ids die du löscht abspeicherst dann weisst du sofort welche noch frei sind ohne sie suchen zu müssen, aber das nimmt bestimmt mehr Platz wech als wenn du den Datentyp gleich auf bigint setzt. Wäre aber bestimmt ne bessere Lösung als der Schleifenlauf

Ja richrig, da kann ich mich nur den Vorschreibern anschließen. Wozu die Lücken auffüllen? Zudem würde ich eh nie eine bereits vergebene ID nach Löschung nochmal verwenden. Wenn einer nicht alle Links zum "deaktivierten Gästebuch" löscht und dann mit dieser ID ein Neues angelegt wird dann landen unter umständen die falschen Besucher im falschen Gästebuch der falschen Seite ;-)

Du kannst ja deinen Usern mitteilen dass sie sich mit Ihren Einträgen im Gästebuch kurz halten sollen, dann sparste garantiert auch Speicher ;-)



Grüße


Rob

Webfriendz wrote:Zudem würde ich eh nie eine bereits vergebene ID nach Löschung nochmal verwenden. Wenn einer nicht alle Links zum "deaktivierten Gästebuch" löscht und dann mit dieser ID ein Neues angelegt wird dann landen unter umständen die falschen Besucher im falschen Gästebuch der falschen Seite ;-)

Wie gesagt, die Datenbank vergibt die ID´s von selber wieder, sobalt diese Frei werden. Man sollte also in so einem Fall das Gästebuch "deaktivierten " und nicht löschen, damit keine falschen, oder toten Links entstehen ...

Gruß Gerd

Man sollte also in so einem Fall das Gästebuch "deaktivierten " und nicht löschen, damit keine falschen, oder toten Links entstehen ...

Oder eben nun doch von PHP oder was auch immer die MaxID+1 nehmen, da kann so was nich passieren.

Webfriendz wrote:Oder eben nun doch von PHP oder was auch immer die MaxID+1 nehmen, da kann so was nich passieren.

nagut, das ist natürlich dann auch eine eindeutige ID ...
Nur wird dann das 'auto_increment' der Datenbank überflüssig, da Du Dich selbst um die Vergabe der ID´s kümmerst.
Es reicht dann ja einen Unique Key auf diese Spalte zu sezten.

nagut, das ist natürlich dann auch eine eindeutige ID ...
Nur wird dann das 'auto_increment' der Datenbank überflüssig, da Du Dich selbst um die Vergabe der ID´s kümmerst.
Es reicht dann ja einen Unique Key auf diese Spalte zu sezten.

Was soll man da noch schreiben ... stimmt :-D