Login: Alle Daten in eine Tabelle?

[Sven]

Hey ihr,

spricht etwas dagegen, dass ich alle Daten eines Users, also:

id, username, password, bday, sex, lang, city...

in eine Tabelle packe? Oder sollte ich eine extra Login-Tabelle erstellen, mit den Daten:

id, username, password

Macht das einen Unterschied?

Lg
Sven

[Tom]

Hello,

spricht etwas dagegen, dass ich alle Daten eines Users, also:

id, username, password, bday, sex, lang, city...

in eine Tabelle packe? Oder sollte ich eine extra Login-Tabelle erstellen, mit den Daten:

id, username, password

Macht das einen Unterschied?

Ja, macht es.
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.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom

[Sven]

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?

Lg
Sven

[Tom]

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

[dedlfix]

echo $begrüßung;

Du must Dir nur merken, was Du zum Betrieb des Potals später dauernd benötigst, und was nur selten.
Also wären zwei getrennte Tabellen dafür besser. Das hält den ständig benötigten Datensatz kleiner.

Wenn man davon ausgeht, dass es nur »SELECT *« gäbe statt »SELECT benötigte_feldnamen« hielte ich eine solche Trennung unter diesem Gesichtspunkt auch für sinnvoll.

Bei einem hoch belasteten System ist eine Trennung nach Session- und Benutzerdaten möglicherweise schon sinnvoll. Wenn die persönlichen Daten der Benutzer ständig gelesen werden, die Verwaltung der Sessiondaten aber aufgrund von Locking-Mechanismen diesen Lesefluss blockiert, stelle ich mir durch die Trennung eine Entlastung des Gesamtsystems vor. Doch wie bei jedem Optimierungsvorgang sollte man diesen Fall genau untersuchen. Erst die wirkliche Ursache von Performance-Engpässen ermitteln, dann gezielt dort ansetzen, sonst optimiert man sich zu Tode, ohne einen Nutzen nachweisen zu können.

echo "$verabschiedung $name";

[Tom]

Hello Dedlfix,

Wenn man davon ausgeht, dass es nur »SELECT *« gäbe statt »SELECT benötigte_feldnamen« hielte ich eine solche Trennung unter diesem Gesichtspunkt auch für sinnvoll.

Das war doch nicht der einzige Grund.
Der zweite ist, dass so jeder Real Life User mehrere Vituals haben kann.

Harzliche Grüße vom Berg
http://bergpost.annerschbarrich.de

Tom