Bitte um Hilfe - Sinnvoller Aufbau einer Mitgliederverwaltung mit MySQL DB

J

Jarez

Neuer Benutzer
Beiträge
3
Hallo,

was MySQL an geht, bin ich Amateur und habe mich aus diesem Grund hier auch angemeldet.

Ich möchte eine Webseite mit einer Mitgliederverwaltung erstellen und bin am Überlegen wie ich die Datenbank sinnvoll aufbaue um nicht später im laufenden Betrieb aus Performance Problemen etwas ändern zu müssen.

Die Nutzer der Webseite sollen sich anmelden können und dann im Mitgliederbereich persönliche Angaben von sich machen können, mit denen für jedes registrierte Mitglied eine Profilseite ausgegeben wird. Für den Mitgliederbereich soll es dann im Anschluss eine Suchfunktion geben.

Meine Überlegungen gehen in Richtung 4 Tabellen.


`member`

id ; AUTO_INCREMENT
userid ; eindeutige ID des Kunden (Unique) – PRIMARY KEY
username
passwort ; verschlüsselt abgelegt
email ; verschlüsselt abgelegt
regdate ; Datum der Registrierung
account_active ; wenn der Account nach Email Bestätigung aktiviert wurde
account_status : werte 1 bis 5 von normales Mitglied -> Supporter -> Adminfunktionen
avatar ; Avatarbild für sein Profil



`member_details`


id ; AUTO_INCREMENT
userid ; eindeutige ID des Kunden (Unique) – PRIMARY KEY
plz ;
wohnort ;
geschlecht ;
geburtsdatum;
text_1 ; Freier Text den das Mitglied schreiben kann.
text_2 ; Freier Text den das Mitglied schreiben kann.
entry_1 ; weitere persönliche Angabe vom Mitglied
entry_2 ; weitere persönliche Angabe vom Mitglied
entry_3 ; weitere persönliche Angabe vom Mitglied
etc. … ich weiß noch nicht welche Angabe ich alle mit rein nehmen werde.


`member_stats`


id ; AUTO_INCREMENT
userid ; eindeutige ID des Kunden (Unique) – PRIMARY KEY
last_login ; letzter Login
profil_hits ; wie oft sein Profil besucht wurde


`member_fotos`

id ; AUTO_INCREMENT
userid ; eindeutige ID des Kunden (Unique) – PRIMARY KEY
filename ; Dateiname
file_checked ; Bild vor dem Freischalten geprüft ?!



Warum diese Aufteilung?

Die Daten in `member` werden so gut wie gar nicht mehr geändert
Die Daten in `member_details` werden ab und zu durch das Mitglied angepasst.
Die Daten in `member_stats` werden regelmäßig häufig durch andere Mitglieder beim Profilbesuch bzw. das System verändert


Ich bin etwas skeptisch was die späteren Suchanfragen betrifft.

Wenn ich auf der Startseite die neusten Mitglieder mit ein wenig Detailangaben anzeigen möchte, müsste ich ja immer `member` mit `member_details` und `member_stats` verknüpft abfragen:

SELECT *
FROM member
INNER JOIN member_details ON member.userid = member_details.userid
INNER JOIN member_stats ON member.userid = member_stats.userid
WHERE `account_active` = '1'
AND last_login != '0'
ORDER BY regdate DESC
LIMIT $limit_start, $limit_ende


Wenn man 10.000 Mitglieder hat, dann braucht doch der Server ewig bis er alle Daten zusammen hat oder nicht?

Was haltet ihr davon? Ist das sinnvoll oder blödsinnig das soweit aufzuteilen?
Ist die Aufteilung so ok und man fragt so was komplett anders ab???
Sollte ich die Datenbank anders aufbauen???

Bin für Anregungen, Hilfe und Kritik dankbar.
 
Werbung:
grob quergelesen:

  • warum immer eine fortlaufende ID und dann nochnals eine ID, die als PK dienen soll? Das kann gern auch die fortlaufende IP sein.
  • ich sehe nur primary Keys, nicht aber Foreign Keys
  • Aufteilung member und member_details halte ich für unsinnig
  • ebenso member_stats
  • text_N und entry_N: was machst Du, wenn N zu klein gewählt wurde? Was für Datentypen willst Du da nehmen? Das wird problematisch, früher oder später...

Allgemein solltest Du prüfen, ob MySQL die perfekte Wahl ist. Was Indexmöglichkeiten und moderne Abfragetechniken und Datentypen anbelangt ist das einige viele Jahre aktuellen Entwicklungen hinterher. Zum Beispiel bei Deiner Abfrage: wenn da irgendwann auch mal viele inaktive Leute wären, könntest Du von einem partiellen Index profitieren (über member.account_active where account_active, Datentyp BOOL vorausgesetzt) oder auch statt regdate gleich ein DATERANGE nehmen, in dem der Account aktiv ist. All das (und viel mehr) kann MySQL nicht.
 
akretschmer schrieb:
grob quergelesen:

  • warum immer eine fortlaufende ID und dann nochnals eine ID, die als PK dienen soll? Das kann gern auch die fortlaufende IP sein.
  • ich sehe nur primary Keys, nicht aber Foreign Keys
  • Aufteilung member und member_details halte ich für unsinnig
  • ebenso member_stats
  • text_N und entry_N: was machst Du, wenn N zu klein gewählt wurde? Was für Datentypen willst Du da nehmen? Das wird problematisch, früher oder später...

Allgemein solltest Du prüfen, ob MySQL die perfekte Wahl ist. Was Indexmöglichkeiten und moderne Abfragetechniken und Datentypen anbelangt ist das einige viele Jahre aktuellen Entwicklungen hinterher. Zum Beispiel bei Deiner Abfrage: wenn da irgendwann auch mal viele inaktive Leute wären, könntest Du von einem partiellen Index profitieren (über member.account_active where account_active, Datentyp BOOL vorausgesetzt) oder auch statt regdate gleich ein DATERANGE nehmen, in dem der Account aktiv ist. All das (und viel mehr) kann MySQL nicht.
Zum Vergrößern anklicken....

Danke für deine Antwort.

Die 'userid' möchte ich nutzen, damit die Nutzer nicht sofort sehen wie viele Mitglieder es aktuell gibt und wie viele Mitglieder sich in welchem Zeitraum angemeldet haben. Aber im Prinzip ist es doppelt gemoppelt. Vielleicht lasse ich die 'id' weg.

Von Foreign Keys hatte ich bisher noch gar nichts gehört.

Entry_1 etc. würde ich schon vorher mit einem richtigen Namen belegen. Ich weiß halt noch nicht wie weit ich die Aufnahmen von Personendaten ausreize. Eigentlich widerstrebt es mir zu viel Daten zu sammeln. Andererseits wäre es für die Zukunft interessant.
 
Die id mußt Du dem User ja auch nicht zeigen. Und das Prinzip von Foreign Keys solltest Du ganz schnell lernen. Um Platz für derzeit noch unbekannte Eigenschaften zu lassen kann man Key-Value-Datentypen (HSTORE) oder JSON-Dokumente (JSON, JSONB) verwenden - in PostgreSQL z.B.
 
Im Zusammenhang mit Foreign Keys solltest du dir Normalisierung auf Wikipedia angucken.
Normalisierung (Datenbank) – Wikipedia
Dir wird dann nicht nur klar werden, wofür FKs gut sind sondern auch das und vor allem warum eine Aufteilung wie die derzeitige eigentlich wenig sinnvoll ist. Das was du bisher abbildest ist eine Tabelle, du zerlegst sie nur aus für dich logischen und nachvollziehbaren Gründen in Bereiche wie häufige Veränderungen und keine Veränderungen, für die Datenbank ist das aber zunächst mal Wurst.
 
Das Ganze ordentlich normalisiert, sollte doch MySql dafür ausreichen.
Aus welchem Grund , ukulele, denkst du dass PostgreSQL besser geeignet ist?
 
Werbung:
@ukulele hat hier gar nicht PostgreSQL ins Spiel gebracht, das war ich. Mit Begründung. Weitere Begründungn findest Du immer wieder mal in meinen Beiträgen.

@LionVI : das Problem mit MySQL ist, daß viele denken: 'ach, dafür reicht das erst einmal aus.' Erst später merken sie, daß MySQL vielleicht doch nicht die Features bietet, die man nun gebrauchen könnte. Datentypen, Indextypen, Abfragetechniken, Join-Typen etc.
 
Zurück
Oben