Ankündigung

Einklappen
Keine Ankündigung bisher.

Datenbank-Design: Profile-Manegement

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Datenbank-Design: Profile-Manegement

    Hallo an alle Lesenden,

    ich mach mir gerade ein paar Gedanken, wie man mehere Profile in einer MySQL-Datenbank verwaltet kann.
    Grundsätzlich geht es momentan um zwei Profile. Anbieter (vendor) und Kunde (costumer).

    Zwei Möglichkeiten, die mir in den Sinn gekommen sind, habe ich mal, exemplarisch, entworfen. (Kein korrektes ER-Modell, soll nur zu Veranschaulichung dienen)

    A (extended profiles)


    B (separeted profiles)


    Die Gemeinsamkeit der Profile liegt quasi im Account (User-Klasse von FOS/UserBundle) Ist es nun sinnvoll, wie in Beispiel A, das Basis-Profil jeweils um ein spezialisiertes Profil zu erweitern.

    Profile = User (in der Anwendung nicht umbedingt notwendig aber möglich)
    Profile + Vendor-Profile = Vendor
    Profile + Costumer-Profile = Costumer

    Oder sind die Gemeinsamkeiten beider Profile zu gering und es ist eher sinnvoll wie in Beispiel B, die Profile zu separieren?

    Oder habt ihr vielleicht noch einen ganz anderen Vorschlag zum Design für mich?

    Freue mich auf eure Antowrten!

    Gruß


  • #2
    Ich würde die gemeinsamen Dinge in eine gemeinsame Tabelle auslagern. Danach würde ich die Unterscheidung über eine Type-Tabelle mit 1:n machen.

    Oder du machst das über ein ENUM. Das wäre sinnvoll, so lange die Menge an Profilen konstant ist.
    GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

    Kommentar


    • #3
      Hab mal versucht, auf Basis deines Vorschlages, einen neuen Entwurf zu erstellen.

      Meintest du so:
      C

      Kommentar


      • #4
        Hey ho,
        wollte nachfragen ob ich zu meinem letzten geposteten Beispiel nochmal Feedback bekommen kann. Bin immer noch auf der Suche nach einer wartungarmen und skalierbaren Lösung. Vielleicht hat ja jemand auch einen anderen bessere Ansatz oder kann mit einen Artikel empfehlen der diese Thematik behandelt. Würde mich über weitere Antworten freuen.

        Gruß

        Kommentar


        • #5
          Tatsächliche Gemeinsamkeiten in ein zentrales Profil zu packen halte ich in den meisten Fällen für sinnvoll.
          Das Ganze jetzt aber noch über ExtendedProfile etc. abzubilden finde ich zum EInen übertrieben, zum Anderen beraubst du dich möglicherweise möglicher ForeignKeys.

          Mal ab von der Idee: du solltest dein Englisch dringend updaten, ein cUstOmer ist ein Kunde, etwas wird confIrmed etc.
          Und ein "expired" macht keinen Sinn wenn es ein "expires_at" gibt, das ist nur unnötiges Fehlerpotential.
          VokeIT GmbH & Co. KG - VokeIT-oss @ github

          Kommentar


          • #6
            Zitat von G.Schuster Beitrag anzeigen
            du solltest dein Englisch dringend updaten
            Da stimme ich dir zu. Der Tippfehler mit Customer und Costumer passiert mir leider zu oft. Bitte das zu entschuldigen. Expired, expired_at und conformation_token kommt vom Symfony2-SfUserBundle-BaseUser. Wollte an den Feldern nichts ändern damit alle Funktionen des Moduls auch laufen.

            Die Gemeinsamkeiten in eine Tabelle ist klar, denke ich. Aber wie assoziiere ich die nicht Gemeinsamkeiten? So das eine übersichtliche Datenbankstruktur entsteht, es einfach ist ein vollständiges Profil mittels Doctrine zu laden und was später eventuell durch weitere "Profile-Typen", wie zum Beispiel Lieferant, erweitern werden kann.

            Kommentar


            • #7
              Hier nochmal mein aktueller Entwurf:


              Wie könnte ich jetzt erweiterte Nutzer-Eigenschaften speichern, die nur von einem Nutzer-Typ genutzt werden?

              Vielleich können folgende Bedingungen meine Anliegen verdeutlichen:
              1. Costumer: account + profile, Role = Costumer
              2. Vendor: account + profile + erweiterte Eigenschaften, Role = Vendor

              Gibt es da irgend ein Best Practice?

              Kommentar


              • #8
                Sieht doch gar nicht so verkehrt aus. Sieht sogar "richtiger" aus als was ich gemacht hätte. Ich würde auf die has-Tabellen verzichten und stattdessen in der phonenumber-Tabelle die Verknüpfung zu profile & phone_type unterbringen. Tatsächlich hast du die Entitäten aber sauberer getrennt. Kommt zusätzlich aber noch ein bißchen auf den Anwendungsfall an.
                "Mein Name ist Lohse, ich kaufe hier ein."

                Kommentar


                • #9
                  Habe deinen Ratschlag mal befolgt. Folgendes ist dabei rausgekommen:


                  So ist der Aufbau etwas einfacher. Frei nach dem Motto "Keep it simple". Finde ich gut. Danke.

                  Hast du vielleicht noch eine Idee bezüglich meiner Frage zu den erweiterten Nutzer-Eigenschaften?

                  Kommentar


                  • #10
                    Zitat von Kinger Beitrag anzeigen
                    Hast du vielleicht noch eine Idee bezüglich meiner Frage zu den erweiterten Nutzer-Eigenschaften?
                    Wenn ich Dich richtig verstehe könntest Du dafür einen Key-Value-Store nehmen, z.B. HSTORE in PostgreSQL. Oder als JSON speichern, also in PG JSON oder, ab 9.4, JSONB.
                    PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                    Kommentar


                    • #11
                      Zitat von akretschmer Beitrag anzeigen
                      Wenn ich Dich richtig verstehe könntest Du dafür einen Key-Value-Store nehmen, z.B. HSTORE in PostgreSQL. Oder als JSON speichern, also in PG JSON oder, ab 9.4, JSONB.
                      Bei den erweiterten Nutzer-Daten handelt es sich nicht nur um Key-Value-Pairs. So soll zum Beispiel die Auswahl einer Kaetgorie gespeichert werden. Also der Admin gibt im Backend 5 Kategorien ein und der Nutzer kann sich dann einer ider mehreren Kategorien zuordnen. Man könnte das bestimmt aich ein einem Key-Value-Pair speichern. Aber ist das nicht zu unübersichtlich? Finde das vom Design dann auch nicht so schön.

                      Ich hab nun auch schon im Netz rauf und runter gesucht, konnte aber keine Beispiele finden, wie andere das machen. Vielleicht kenn ja jemand von euch ein Beipiel. Vorstellen tue ich mir sowas ähnliches wie in Post #3. Weiß nur nicht ob man das so machen kann und ob das dann auch (sauber) programmierbar ist.

                      Kommentar


                      • #12
                        Zitat von Kinger Beitrag anzeigen
                        Also der Admin gibt im Backend 5 Kategorien ein und der Nutzer kann sich dann einer ider mehreren Kategorien zuordnen.
                        Dafür wurden Tabellen und Foreign Keys erfunden.
                        PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                        Kommentar


                        • #13
                          Zitat von akretschmer Beitrag anzeigen
                          Dafür wurden Tabellen und Foreign Keys erfunden.
                          Korrekt. Jetzt bin ich nur auf der Suche nach einer eleganten Lösung dies in mein obriges Design einzuarbeiten.

                          Kommentar


                          • #14
                            Habe jetzt einmal eine Lösung modelliert.


                            Ist in der Tabelle "profile" der FK für Vendor gesetzt ist der User ein Anbieter sonst ein Kunde. Ich denke, dass kann man programmatisch auch beim laden der Daten prüfen und dann gegebenenfalls drauf reagieren.

                            Aber ist das noch elegant wenn weitere Profile wie Vendor hinzukommen? Würde die Tabelle "profile" ja um weitere FK's erweitern.

                            PS: Wenn ich das richtig sehe ist die Beziehung zwischen profile -> vendor falsch herum. Bitte anders herum sehen.

                            Kommentar

                            Lädt...
                            X