Screeny

Hallo!

Ich arbeite derzeit an einem "Fun" - Projekt um meine PHP / SQL - Fähigkeiten wieder etwas aufzufrischen bzw. zu erweitern. Ich hab mir ein kleines eigenes Projekt gesetzt und versuche das nun weitgehend zu realisieren. Auf meinem local versteht sich.

Ich habe vor, dass sich ein User registrieren kann und ein Profil für sich anlegen kann um dort entsprechende Informationen über sich zu speichern.

Jetzt überlege ich wie ich die Datenbank "designe". Lass ich die Benutzerdaten alle über eine Tabelle in der DB laufen, lege ich eine für den login an, eine für diesen Bereich und noch eine für diesen.

Mir stellt sich die Frage, was wäre, wenn z.B. 4000 User registriert WÄREN.
Wie sollte man eine DB am besten von Anfang an designen um z.B. später eine gute Performance beizubehalten.

Ich würde mich sehr über eure Erfahrugen freuen!

Vielen dank im voraus!

Screeny

Mister Ad

nikosch

Im Allgemeinen reicht eine Datenbank mit mehreren Tabellen. Für Projekte, die später auf einen Hoster umziehen, der viell. nur eine Datenbank anbietet, empfiehlt sich zusätzlich ein Namespcae-Prefix der jeweiligen Anwendung für die Tabellen zu benutzen.

__________________
--
One pixel is still too big. Please make it smaller. ASAP.

Initiative Mittelstand.
Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers.
--

MaiKaY

Bei mehreren User würde ich Kreuz Tabellen anlegen :P

1. User
2. UserAttribute
3. User_x_UserAttribute

so in der Art

__________________
ACHTUNG!!! SIGNATUR!!!
0 ??? WTF ? freutag.net

mepeisen

Eine Kreuztabelle macht nur dann Sinn, wenn sich mehrere User ein und dasselbe Attribut teilen. Und das ist ein eigentlich alberner Ansatz, denn wieso sollte die gleiche ICQ-Nummer bei mehreren Usern zum Einsatz kommen. Selbst wenn sich beispielsweise der Wohnort von zwei Usern zufällig gleicht, ist das kein grund, eine Kreuztabelle anzulegen.

So, nun kommt das Aber. Es gibt einzelne Attribute, wo das wiederum Sinn macht. So beispielsweise die "Rolle". Also der Wert ob man Besucher oder Admin der Webseite ist.

__________________
www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

MaiKaY

oO... was erzählste da fürn shice Kreuztabellen machen wohl in der hinsicht Sinn... Aber nun ja Jeder macht es auf seine Art und Weise.

-> Habe ja nur gepostet, wie ich meine DB "designe"

__________________
ACHTUNG!!! SIGNATUR!!!
0 ??? WTF ? freutag.net

Screeny

Danke für die schnellen Antworten!

Was spricht denn dagegen in der Tabelle "User" einfach alle Infos zu speichern?

also z.B.:
User | Mail | PW | Wohnort | ICQ | Hobbys | Angemeldet am | Strasse | Plz usw.

Wird die DB dadurch langsamer?

MaiKaY

Die Performance wird einfach schlechter, wenn viele User gleichzeitig zugreifen. Bei wenigen Benutzern, ist das gar kein Problem, aber du hast ja gefragt bei 4000 User...

__________________
ACHTUNG!!! SIGNATUR!!!
0 ??? WTF ? freutag.net

Screeny

Das hatte ich mir fast gedacht. Gut. Ich werd dann mal ein wenig an meinem localhost Projekt weiterbasteln.

Was noch sehr hilfreich wäre:

Wie verbinde ich denn idealerweise die Inhalte aus den drei Tabellen

Bspl:
1. User
2. UserAttribute
3. User_x_UserAttribute

in 1. sind id, user und pw
in 2. paar Infos
in 3. weitere infos

Wie schreibe ich die Daten denn am besten in die DB, dass die user mit den entsprechenden für sie bestimmten Daten verbunden werden können?

Möglich wäre ja, die incrementierte ID auszulesen und mit in Tabelle 2 und 3 zu schreiben und dann unter dieser ID die Daten zu speichern. Damit dann die ID und die zugehörigen Daten abrufen und "verknüpfen".

Oder habt ihr da einen besseren Weg?

Danke für die schnelle Hilfe!

Dark Guardian

Begründung?

User:

id, name, pw

UserAttr

id, user_id, icq, msn, wohnort, hobbys, email

User_x_UserAttr

????

Und selbst wenn du die Tabelle UserAttr nach dem Schema "id, user_id, attr, value" aufbaust ist die dritte Tabelle Sinnlos weil

Das ist und bleibt eine 1 zu n beziehung und wird niemals eine n zu m Beziehung werden, alles andere wäre designtechnisch problematisch.

Performance. Vorallem weil einige Felder vom Typ varchar() sein werden und somit die Länge eines Datensatzes nicht 100%ig sicher ist.

Bei 4000 gehts noch, aber ich durfte neulich an einem DB Design für 4 Millionen Datensätze mitwirken, und da macht es schon was aus wenn aus 20 Spalten nur noch 10 werden weil die restlichen ausgelagert werden konnten da sie nur auf "einer" Seite im System gebraucht werden.

Screeny

Könnte ich es denn z.B. so machen ? :

user | logindaten
useratt | 10 Benutzerinfos
useratt2 | 10 weitere Benutzerinfos