Anzeige:
Ergebnis 1 bis 7 von 7

Thema: Empfehlung/Verbesserung für Datenbankmodell

  1. #1
    Registrierter Benutzer Avatar von DarkSorcerer
    Registriert seit
    03.04.2003
    Ort
    Mannheim
    Beiträge
    44

    Empfehlung/Verbesserung für Datenbankmodell

    Hallo zusammen,

    ich möchte ein DB Modell entwerfen zu folgendem Szenario. Ich habe bereits eine Idee, bin aber gerne offen für Vorschläge und Verbesserungen.

    Es soll eine Art Verteiler erstellt werden. D.h. ein User authentifiziert sich gegenüber dem System mit seinem Username (z.b. user_xy) und hat die Möglichkeit, eine unbestimmte Menge an Verteilerprofilen anzulegen. Als Bsp: Er legt zwei Profile an (Profil1 und Profil2).

    Er kann eine unbestimmte Menge an Personen jedem Profil zuweisen.
    Profil 1 werden z.b. 2 Personen zugeordnet (user_1 und user_2).
    Profil 2 wird 1 Person zugeordnet (user_3).

    Das ganze sieht dann so aus:
    Angemeldeter User: user_xy
    Erstelle profile: Profil1, Profil2
    Personenzuordnung zu Profil1: user_1, user_2
    Personenzuordnung zu Profil2: user_3

    Folgendes sollte beachtet werden:
    Die User id, mit der sich ein Benutzer am System authentifiziert, ist einmalig. Es können sich eine unbestimmte Menge an unterschiedliche User am System authentifizieren und profile erstellen sowie Personen zuweisen. Es kann vorkommen, dass unterschiedliche Personen zufällig den gleichen Profilnamen erstellen und teilweise gleiche Personen dem Profil zuordnen (muss aber nicht). Diese Profile sind also völlig unabhängig voneinander.

    Folgende DB Struktur habe ich mir überlegt:
    PHP-Code:
    Tabelle1USERACCOUNTS
    id   
    user_name
    --------------------
    1    user_xy
    2    
    user_1
    3    
    user_2
    4    
    user_3
    …usw 
    Id ist der primary key
    Der user_name repräsentiert den Namen, mit der sich ein User authentifiziert.

    PHP-Code:
    Tabelle2PROFILES
    id   
    profile_name  user_id
    -----------------------------------
    1    Profil1       1
    2    
    otherProfile  2
    3    
    Profil2       1
    …usw 
    Id ist der primary key
    Profile_name ist der vom user gewählte profilname
    User_id repräsentiert die id des users aus tabelle USERACCOUNTS, d.h. in dem Bsp, dass user_xy 2 profile hat: Profil1 und Profil2.
    User_1 hat 1 profil angelegt: otherProfile

    PHP-Code:
    Tabelle3PROFILEMAPPING
    id   
    user_id            profile_id
    -------------------------------------
    1    user_1             1
    2    
    user_99            2
    3    
    user_2             1
    …usw 
    Id ist der primary key
    User_id ist die id der Person, die dem Profil zugeordnet wurde
    Profile_id ist die id zur Zuordnung des Users zu einem Profilnamen. User_1 und user_2 sind beide der profile_id 1 zugeordnet. Die profile_id 1 steht in Tabelle PROFILES für „Profil1“. Es kann durchaus vorkommen, dass in unterschiedlichen profilen die gleichen Personen drin sind. Somit ist die Spalte user_id und profile_id nicht unique. Daher habe ich die Spalte id noch hinzugefügt.

    Es besteht bereits eine weitere tabelle, die die user_id (z.b. user_1 oder user_2) als primary key hat und dazu dann personendaten wie anschrift etc beinhaltet.

    Soweit meine Überlegung. Da unterschiedliche User einen gleichen Profilnamen wählen könnten, wüsste ich nicht, wie man das noch vereinfachen könnte. Falls jemand Vorschläge, Ratschläge oder Tipps zur Verbesserung hat, freue ich mich auf eure Antworten.

    Grüße
    Registered Linux User #313702
    WS #1: 2,2 GHz P4 | 512 MB RAM | 80 GB HDD | GF4 Ti 4200 | SB Audigy :::> Gentoo Linux stage1, vanilla-sources
    WS #2: 1 GHz Athlon B | 512 MB RAM | 60 GB HDD | GF2 Pro 64 MB | SB Live :::> Debian Sid, Kernel 2.4.22
    WM: Fluxbox 0.1.14, the one and only :)

  2. #2
    Registrierter Benutzer Avatar von BLUESCREEN3D
    Registriert seit
    08.11.2002
    Beiträge
    665
    USERACCOUNTS: UNIQUE (user_name)
    PROFILEMAPPING: id raus und PRIMARY KEY (user_id, profile_id)
    Und alle Spalten NOT NULL. Höchstens PROFILES.user_id NULL, falls die Profile bei User-Löschungen weiterexistieren sollen.
    Hast du FOREIGN KEY angegeben?

    Es besteht bereits eine weitere tabelle, die (...) personendaten wie anschrift etc beinhaltet.
    Könntest du auch mit in USERACCOUNTS packen.

  3. #3
    Registrierter Benutzer Avatar von DarkSorcerer
    Registriert seit
    03.04.2003
    Ort
    Mannheim
    Beiträge
    44
    danke für die info, habs angepasst.
    Fremdschlüssel sind wie folgt:
    USERACCOUNTS: user_name ist PK und FK
    PROFILES: id=PK, user_id=FK
    PROFILEMAP: (user_id, profile_id)=PK, profile_id=FK

    Felder sind alle NOT NULL. wenn ein user gelöscht wird sollen auch seine profile sowie die user zuordnung nicht mehr existieren. genauso ist es, wenn ein profil gelöscht wird. dann soll die user zuordnung ebenso gelöscht werden.

    kann man das so lassen oder kann man noch was verbessern?
    Registered Linux User #313702
    WS #1: 2,2 GHz P4 | 512 MB RAM | 80 GB HDD | GF4 Ti 4200 | SB Audigy :::> Gentoo Linux stage1, vanilla-sources
    WS #2: 1 GHz Athlon B | 512 MB RAM | 60 GB HDD | GF2 Pro 64 MB | SB Live :::> Debian Sid, Kernel 2.4.22
    WM: Fluxbox 0.1.14, the one and only :)

  4. #4
    Registrierter Benutzer Avatar von BLUESCREEN3D
    Registriert seit
    08.11.2002
    Beiträge
    665
    Zitat Zitat von DarkSorcerer Beitrag anzeigen
    USERACCOUNTS: user_name ist PK
    Ich dachte, die id ist PK. Alles andere kannst du so lassen.

  5. #5
    Registrierter Benutzer Avatar von DarkSorcerer
    Registriert seit
    03.04.2003
    Ort
    Mannheim
    Beiträge
    44
    da der user_name auch unique ist, kann man die id eigentlich weg lassen. wäre nur eine unnötige abfrage mehr.
    Registered Linux User #313702
    WS #1: 2,2 GHz P4 | 512 MB RAM | 80 GB HDD | GF4 Ti 4200 | SB Audigy :::> Gentoo Linux stage1, vanilla-sources
    WS #2: 1 GHz Athlon B | 512 MB RAM | 60 GB HDD | GF2 Pro 64 MB | SB Live :::> Debian Sid, Kernel 2.4.22
    WM: Fluxbox 0.1.14, the one and only :)

  6. #6
    Registrierter Benutzer Avatar von BLUESCREEN3D
    Registriert seit
    08.11.2002
    Beiträge
    665
    Dann musst du aber überall, wo du auf Benutzer verweisen willst, den kompletten Benutzernamen speichern und das verbraucht wesentlich mehr Speicher als ein INT als ID.

  7. #7
    Registrierter Benutzer
    Registriert seit
    07.05.2007
    Beiträge
    656
    Moin,

    Zitat Zitat von BLUESCREEN3D Beitrag anzeigen
    Dann musst du aber überall, wo du auf Benutzer verweisen willst, den kompletten Benutzernamen speichern und das verbraucht wesentlich mehr Speicher als ein INT als ID.
    kommt auf die DB an. In Oracle wird Integer z. B. intern als number(38) abgelegt - da sind die o. g. Benutzernamen auch nicht länger (und mit varchar kannst Du u. U. auch noch sparen). Außerdem benötigst Du weniger Platz, weil Du keinen zusätzlichen Unique Index auf den Benutzernamen legen musst (zur Gewährleistung der Eindeutigkeit).

    Jan

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •