[php] 1.4 milli keys generieren?

[Jens Vollmer]

> > 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

danke an euch alle,

werd jetztma alle informationen sammeln und mich durch enums indexe u.s.w diurchschlagen
wie gesagt, hab nicht die mysql erfahrung um das jetzt so "hinzurotzen". 
aber mit hilfe eure beiträge kann jetzt nichts mehr schiefgehen.

viele grüße,
jens