[php] 1.4 milli keys generieren?

[Beck, Mike]

> hm, ein enum-Feld für J,N braucht wohl genausoviel bytes
> wie ein Char-Feld....

glaube ich nicht - ein enumfeld für j/n kann für mysql nur 0 oder 1 haben -
ein char hat mehr als einen einstelligen integerwert - ausserdem wird mit
enum sichergestellt dass kein müll drin steht

> deswegen würd ich letzteres nehmen,
> das machts einfacher.
> Den Datensatz zu löschen, halte ich für wenig sinnvoll,
> da wie du schon schreibst, das wesentlich länger dauert,
> den Index über die Zufallszahlen neu aufzubauen. (Wäre
> eigentlich ein super Anwendungsfall für Oracles Indexbased
> Tables oder wie die Dinger heißen ;)

was machen die den anders/schneller?


> ein Index auf die Enum/Char-Spalte mit geloescht j/n macht
> kein Sinn, denn wenn die ~ haelfte der Nummern verbraucht
> ist, wird der gar nicht verwendet...

eben - auch wenn nicht - angenommen es sind nur 20.000 der einträge gelöscht
- ist schneller er sucht sich den eintrag den ich haben will und prüft ob er
gelöscht ist als er sucht sich die 20.000 und prüft jeweils ob der schlüssel
passt - wie gesagt es kann nie mehr als ein index auf einmal verwendet
werden

> update tabelle set gebraucht='j' where schluessel=pruefschluessel
> and gebraucht='n'

das and gebraucht kannste eigentlich weglassen - mysql prüft selbst ob es
notwedig ist die spalte zu ändern und wird dir, wenn der schlüssel bereits
auf 'N' stand auch ein affected_rows von 0 ausgeben

> Der update kostet dich so viel wie das select (denk ich mal :)

eben weil auf dem enum kein index ist - dauern tut ein update nur, wenn ich
deswegen einen index neu aufbauen muss

--
Mike Beck
mike.beck_(at)_users.sourceforge.net