Ankündigung

Einklappen
Keine Ankündigung bisher.

Datenbankdesign

Einklappen

Neue Werbung 2019

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

  • Datenbankdesign

    Hallo,

    war mir nicht sicher ob das Thema hier hingehört, da es sich grundlegend um die Datenbank handelt, ich aber nach der Diskussion- oder wärend dessen - über das Datenbankdesign auch auf das Softwaredesign eingehen möchte.

    ich bin dabei eine Software zu planen und sitze gerade am Datenbankdesign.

    Mir ist es wichtig, dass ich Entitäten wie z.B. Benutzer, Rolle, Gruppe, Domäne, Kontakte, Projekte etc. möglichst einheitlich behandeln kann um den implementierungsaufwand so gering wie möglich zu halten und um das Rechtemanagement - welches im Datenbangdesign noch nicht berücksichtigt wurde - zu vereinfachen. Außerdem muss gewerleistet sein, dass alle Metadaten auch sprachabhängig gespeichert werden können.

    Mein derzeitiges Ergebnis habe ich angehängt. Wie bereits erwähnt fehlt derzeit noch eine Tabelle für Rechte und deren Vergabe auf Objekte.

    Ich bin gespannt was für Verbesserungsavorschläge ihr habt und freue mich über Tipps bzw. Erfahrung bezüglich Performance und Skalierbarkeit bei großen Datenmengen.

    Viele Grüße
    Angehängte Dateien

  • #2
    Nested Set

    Um die Performance zu steigern, habe ich die Tabelle object_link zu einem Nested Set abgeändert und auf die hierarchische Darstellung über id und parent verzichtet.

    Außer das es beim einfügen von Knoten länger dauert, sehe ich kein Nachteil bei dem Konzept... Ihr!?
    Angehängte Dateien

    Kommentar


    • #3
      Um es ein bisschen besser zu verdeutlichen was mein Ziel ist.

      Hier mal die Struktur die ich abbilden möchte:
      Globale Domöne
      -> Gruppe A
      ---> Benuter A
      -> Rolle A
      ---> Benutzer A
      Domäne A
      -> Gruppe B
      ---> Benuter B
      -> Rolle B
      ---> Benutzer B
      -> Website A
      ---> Page A

      Jeder Knoten wird im DB Model als Objekt bezeichnet.

      Kommentar


      • #4
        Mir ist es wichtig, dass ich Entitäten wie z.B. Benutzer, Rolle, Gruppe, Domäne, Kontakte, Projekte etc. möglichst einheitlich behandeln kann um den implementierungsaufwand so gering wie möglich zu halten
        Alle gleich behandeln? Eine Rolle ist rein aus Sicht ihrer Domänen-Funktion etwas deutlich anderes als beispielsweise ein Artikel.
        Viele Grüße,
        Dr.E.

        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        1. Think about software design [B]before[/B] you start to write code!
        2. Discuss and review it together with [B]experts[/B]!
        3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
        4. Write [I][B]clean and reusable[/B][/I] software only!
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

        Kommentar


        • #5
          Alle gleich behandeln? Eine Rolle ist rein aus Sicht ihrer Domänen-Funktion etwas deutlich anderes als beispielsweise ein Artikel.
          Ich habe auch schon überlegt die Domäne, Rolle, Gruppe und Benutzer aus der Objekt Struktur zu nehmen und nur noch Dinge wie Projekt, Artikel, News etc. darüber zu verwalten.

          Bei der Zuordnung Benutzer -> Gruppe und Benutzer -> Rolle würde ich aber wieder ähnliche, wenn nicht sogar gleiche, Tabellen anlegen. Ich würde gerne alles so generisch wie möglich machen um redundanzen und zusätzlichen Implementierungsaufwand in der Programmierung zu sparen.

          Kommentar


          • #6
            Hier wäre ein Modell in dem die Domäne, Gruppe, Rolle und der Benutzer gesondert behandelt werden.

            Nur wie geht man jetzt mit den Sprachabhängigen Daten dieser Entitäten um. Vorher konnte man diese Daten in einer gemeinsamen Tabelle speichern, da die Beziehung klar war. Jetzt müsste ich eine neue Tabelle einführen oder die Übersetzung mittels PHP machen.

            Genau das ist der Punkt wo es derzeit bei mir harkt und zusätzlich noch die Performance, da doch viel joints verwendet werden müssen um an alle Daten eines Objekts zu kommen.
            Angehängte Dateien

            Kommentar

            Lädt...
            X