nicht angemeldet
Hello,
Mit der Eintabellenlösung kann jeder reale User auch nur einen virtuellen User haben.
Mit der Zweitabellenlösung kann jeder reale User beliebig viele virtuelle User, sogar mit unterschielichen Rechten, haben.Hey,
achso... und von der Geschwindigkeit her? Die Admins haben ihren eigenen Zugang, bei den Usern gibt es keine unterschiedlichen Rechte. Aber wäre es ein Geschwindigkeitsvorteil, die Zweitabellenlösung zu verwenden?
Es ist ein konzeptioneller Unterschied.
Du must Dir nur merken, was Du zum Betrieb des Potals später dauernd benötigst, und was nur selten.
Wenn ein User sich angemeldet hat unter seinem sicherlich eineindeutigen Loginnamen und seinem Passwort, dann wirst Du doch wahrscheinlich Daten, wie seine emailadresse, seine Kontonummer, seine Wohnanschrift und seinen Klarschriftnamen nicht bei jedem Request benötigen, aber seinen Nickname, seine Rechte, je nach Sesssionverfahren auch das Passwort (wenn Du die Session über Auth Basic führen willst und nicht über Cookie).
Also wären zwei getrennte Tabellen dafür besser. Das hält den ständig benötigten Datensatz kleiner.
Übrigens habe ich immer drei Tabellen, weil ich die Rechte noch wieder in einer eigenen Tabelle führe. Erstens gibt es diverse verschiedene Rechte (es könnte auch mal eines dazukommen) und außerdem unterschiedlicze Module. Für jedes entsteht dann pro User ein Datensatz.
Fang also mit zwei Tabelen an, trenne zwischen Wirtschafts- und Webdaten des Users, nimm die Adminsitratoren mit rein in die Verwaltung (warum zwei Systeme, wenn es eins auch tut?). Noch ein Tipp. Der "Notadmin bekommt die die Usernummer 1 (so ähnlich, wie bei Linux mit der 0) und Dein Programm sträubt sich "hartverdrahtet", die zu löschen, wobei die 1 jeztzt nur als Beispiel dient, weil Du von dort aus weiterzählen lassen kannst.
Was benötigst Du dann für den Datensatz?
userlogin
---------
id_userlogin bigint autoincremt primary ## id des datensatzes, eigentlich redundant
id_useroffline biging indexed # zu Nickname, aber _nicht_änderbar_
writecount bigint ## für konkurriernden Betrieb
lastvisit timestamp
inserted datetime
updated datetime
nickname varchar (30) indexed unique ## änderbar
password varchar (16)
session varchar (16)
enabled tiniint (1)
rights varchar (100) ## das sollte man später auslagern
Mehr fällt mir jetzt nicht ein
Vielleicht weiß sonst noch jemand was.
Was muss impelementiert werden?
Welche MySQL-Version hast Du?
Wie sicher (und komplex) willst Du es machen?
Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau
Ein Jammer ist auch, dass die Dummen so selbstsicher und die Klugen voller Zweifel sind. Das sollte uns häufiger zweifeln lassen :-)
