1. Willkommen im Forum für alle Datenbanken! Registriere Dich kostenlos und diskutiere über DBs wie Mysql, MariaDB, Oracle, Sql-Server, Postgres, Access uvm
    Information ausblenden

Bitte um Hilfe - Sinnvoller Aufbau einer Mitgliederverwaltung mit MySQL DB

Dieses Thema im Forum "MySQL und MariaDB" wurde erstellt von Jarez, 29 Mai 2017.

  1. Jarez

    Jarez Neuer Benutzer

    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.
     
  2. akretschmer

    akretschmer Datenbank-Guru

    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.
     
  3. Jarez

    Jarez Neuer Benutzer

    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.
     
  4. akretschmer

    akretschmer Datenbank-Guru

    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.
     
  5. ukulele

    ukulele Datenbank-Guru

    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.
     
    Walter gefällt das.
  6. Jarez

    Jarez Neuer Benutzer

    Danke für Eure Infos und den Link.
    Ich schaue es mir nachher an.
     
  7. LionVI

    LionVI Benutzer

    Das Ganze ordentlich normalisiert, sollte doch MySql dafür ausreichen.
    Aus welchem Grund , ukulele, denkst du dass PostgreSQL besser geeignet ist?
     
  8. akretschmer

    akretschmer Datenbank-Guru

    @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.
     
Die Seite wird geladen...

Diese Seite empfehlen

  1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden