• Das Erstellen neuer Accounts wurde ausgesetzt. Bei berechtigtem Interesse bitte Kontaktaufnahme über die üblichen Wege. Beste Grüße der Admin

2 kleine Fragen

W

wagi

User
Wenn ich eine ID mitels auto_increment immer um 1 erhöhe wenn sich ein User anmeldet, ich jedoch einen User lösche aber abhängig von der genauen ID bin - was mach ich dann. Gibts ne Lösung das zu umgehen??

2te fällt mir nimma ein :)
 
also, ein User meldet sich an, bekommt automatisch die ID 1, da auto_increment, User 2 bekommt ID 2 usw.

Nun wenn ich einen User auf Grund von Fehlverhalten ect. löschen will benutz ich ja Drop ... where ID = 2

Dann fehlt ja praktisch der User 2, da ja die ganze Zelle gelöscht wurde.

Also es existiert
USER 1
User 3
User 4

Wenn ich aber nun abhängig bin von der ID, beispielhalber wenn ich alle User auflisten will, existiert USER 2 ja nicht mehr und das führt dann doch unweigerlich zu Problemen.

Dass heisst der User der sich als nächster anmeldet sollte wieder die ID 2 zugewiesen bekommen, der übernächste dann wieder bei 5 weiter...

Löschen und Eintragen ist eher zeitlich getrennt!
 
hmmm wo ist da das Problem???
beim Anzeigen der User machst Du doch ein "Select * from Users"... da kriegst Du die korrekte ID zum korrekten Usernamen... wenn Du dann in der Anzeige nur die Namen anzeigst, dann kann dahinter ja trotzdem die ID in der URL <a href="userloeschen.php?id=<?php echo $user_id ?>"> versteckt sein, oder??
 
was mach ich jedoch wenn ich sie nach id ordnen will.

Oder aderes beispiel. Es handelt sich nicht m User sondern um Artikel. Ich hab ne Navigation die immer um +1 die Anzahl der IDs hinaufzählt. Wenn da einer fehlt bekomm ich doch ne Fehlermeldung!
 
dann hast Du möglicherweise einen Designfehler....

eine Sortierung nach ID ist doch ohne Probleme möglich (z.B. order by user_id)... was das allerdings bringt ist fraglich, denn die ID ist ja in der Regel nur für die DB und Deine Skripte von Interesse, der Admin sieht so höchstens die Reihenfolge, in der die User / Artikel / Datensätze angelegt wurden... ein Datum wäre da hilfreicher...

Was isn das für eine Navigation?? Wenn die selbst ausrechnet, welche IDs in der DB sein müßten, ohne die zu fragen die es wissen müßte (die DB selbst ;) ), dann siehe oben -> Designfehler....

P.S.: bevor sich die DesignerInnen angegriffen fühlen, ich rede vom Softwaredesign... ;););)
 
auto_increment schafft die Grundlage für Eindeutigkeit in der DB.
Dass die userID nicht mehr neu vergeben wird, ist sehr sinnvoll. Angenommen du hast ein relationales Datenbankmodell, dann kann ja sein, daß mittels dieser eindeutigen ID, andere Einträge in anderen Tabellen dieser ID zugeordnet sind. Falls beim löschen nicht alle Tabellen durchkämmt werden, gibts bei der erneuten Vergabe dieser ID ein Chaos in der DB.

Ein Problem bei der Ausgabe kann ich nicht erkennen.

Wenn Du das aber unbedingt anders willst, dann lass auto_increment weg und mach ein php-script für die id-vergabe.

odyss
 
was odyss sagt ist auch ein Punkt, den man bedenken sollte... zumal mysql kein kaskadierendes Löschen anbietet, dann wäre das einfacher... Du löscht den User, die DB Skripte/Trigger machen den Rest.... ;)
 
yop, gut, reicht, stop aufhören *grins*

dann mach ichs eben anders!
danke, das war eine der fragen, die ich nicht lösen konnte, und da es keine Möglichkeit gibt, wie ihr hier berichtet habt, die auto_increments nach Löschen zu verfollständigen, umgeh ich einfach das problem.

THanx
 
Die Schleife in der Ausgabe, zählt nicht die id`s hoch, sondern nur die tatsächlichen Treffer aus der DB-Abfrage.

Bsp: Hans ID=1
Franz ID=3
Dampf ID=5

Das result-array enthält 3 Datensätze

1.Datensatz $i=0 : record[$i][id] = 1;
2.Datensatz $i=1 : record[$i][id] = 3;
3.Datensatz $i=2 : record[$i][id] = 5;

odyss
 
schon klar, dann muss ich halt die id in "echtzeit" jeweils zuordnen und erzeugen!

Jetzt ist mir auch wieder meine 2te eingefallen:
Für eine Art Login Center, bei dem die nächstfolgenden Aktionen alle abhängig sind, ob man eingeloggt ist oder ob man nicht eingeloggt ist und somit die aktionen nicht ausführbar sein sollten, soll ich da über reine Cookies programmieren, oder über Sessions. Gibts da Vorteile bei den Sessions?? Oder gibts überhaupt noch andere Möglichkeiten das zu lösen??
 
Gegen cookies spricht der Umstand, daß sie bei manchen Usern deaktiviert sind. Dann funzt die Sache nicht mehr.
Mit session umgeht man das Problem. Aber Vorsicht. Default ist auch die sessionID cookiebasierend, dann hat man wieder das gleiche Problem.
Das kann man mit einem fallback beheben. Die sessionID wird dann bei jedem Link manuell als Parameter übergeben, oder der Server hängt sie automatisch dran. siehe -> enable-trans-sid

odyss
 
aber grundsätzlich gehts auch mit reinen cookies -

könnte man diesen Fallback nicht auch ohne Sessions einbauen und somit allen links einfach ?password=kjdsb?name_id=bdabfid
anhängen und somit immer die Logindaten auslesen ohne dass Cookies benötigt werden??
 
stimmt, funzt auch.

Hat aber den Nachteil, daß während der ganzen Sitzung auf der Seite, die Zugangsdaten in der URL im Klartext auch für Dritte ersichtlich sind.

odyss
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben