Ankündigung

Einklappen
Keine Ankündigung bisher.

Frage zur Tabellen Verknüpfung (MySQL Workbench): User & Media Tabelle

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

  • Frage zur Tabellen Verknüpfung (MySQL Workbench): User & Media Tabelle

    Hallo!

    Ich muss wohl eingestehen, dass ich was Datenbankschema angeht, ein wenig aus der Übung gekommen bin. Ich habe zur Auffrischung als Lernprojekt eine Art Ticketsystem ausgesucht und ich frage mich ob folgendes Schema, welches ich mit Mysql Workbench aufgebaut habe korrekt wäre?

    Ich hatte es einmal getestet und die Verbindung zu user <-> media scheint bereits ein Problemfall zu sein, so also nicht zu klappen. Was habe ich also vor?

    Im Prinzip, soll das Datenbankschema Folgendes abbilden:



    Ein user erstellt ein media Eintrag und die user_id je media Eintrag bezeichnet den Ersteller. Ein user kann (optional) jedoch auch ein Profilbild haben. Hier müsste der user also eine Zuordnung zu einem media Eintrag erhalten. Ein Projekt hat mehrere bugs, ein bug mehrere Kommentare (comment) und sowohl einem Bug, als auch einem Kommentar können ein oder mehrere media Files zugeordnet werden.

    Wie würde man hier, insbesondere die Verknüpfungen rund um media, korrekt abbilden?

    Vielen Dank!


  • #2
    Auf jeden Fall lesbarer... Ne ehrlich, das kleine Bildchen kann doch keiner lesen...
    Competence-Center -> Enjoy the Informatrix
    PHProcks!Einsteiger freundliche Tutorials

    Kommentar


    • #3
      Zitat von Arne Drews Beitrag anzeigen
      Auf jeden Fall lesbarer... Ne ehrlich, das kleine Bildchen kann doch keiner lesen...
      Sry da war beim Editieren wohl ein Fehler unterlaufen und die Verlinkung ging weg. Nun ist es in groß

      Kommentar


      • #4
        Soll es wirklich nur eine 1:1 Beziehung zwischen user und media geben? Warum sollte ein User nicht mehrere Medien anlegen dürfen?
        bug_project_id - was soll das sein? Sollte es dazu nicht auch noch eine Zwischentabelle geben? Denn dann wäre bug_id in den Tabellen comment und bug_has_media unnötig.
        media.filetype könnte man noch normalisieren.

        Ansonsten siehts doch recht brauchbar aus
        Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

        Kommentar


        • #5
          Hmmm... Gibt sicher unterschiedliche Ansätze, ich tendiere bei sowas zu Mapping-Tables.
          Am Beispiel von User:Media in etwa so:
          Code:
          // table: Users
          Id : auto_increment
          UserName : varchar
          
          // table: Media
          Id : auto_increment
          MediaPath : varchar
          MediaType : varchar
          MediaSize : decimal
          und dazu eben eine dritte Tabelle:
          Code:
          // table: UsersMediaMapping
          Id : auto_increment
          UserId : int
          MediaId : int
          Und das eben für die anderen Abhängigkeiten auch.
          ​​​​​​​
          Competence-Center -> Enjoy the Informatrix
          PHProcks!Einsteiger freundliche Tutorials

          Kommentar


          • #6
            Zitat von lstegelitz Beitrag anzeigen
            Soll es wirklich nur eine 1:1 Beziehung zwischen user und media geben? Warum sollte ein User nicht mehrere Medien anlegen dürfen?
            bug_project_id - was soll das sein? Sollte es dazu nicht auch noch eine Zwischentabelle geben? Denn dann wäre bug_id in den Tabellen comment und bug_has_media unnötig.
            media.filetype könnte man noch normalisieren.

            Ansonsten siehts doch recht brauchbar aus
            Die user_id (1: ) in der Tabelle media (:n) entspricht ja quasi dem creator (also die user_id, des Nutzers, der das File hochgeladen hat). Die media_id (1: ) bei user (: 1) ist eine 1:1 Verbindung, weil dem User nur ein Profilbild zugeordnet werden sein soll. Dies führt so wie aktuell umgesetzt jedoch zu einem Fehler beim Import des SQL. Da MySQL offenbar hier eine gegenseitige Referenzierung sieht und dies nicht erlaubt ist? Ich frage mich dann nur wie in solchen Anwendungsfällen mit sowas umgehen, ohne unnötigerweise eine n:m Tabelle zu erzeugen. Denn ein Nutzer hat maximal ein Profilbild und nicht mehrere. Ein Nutzer kann jedoch mehrere Bilder erstellen. Ein Bild gehört jedoch NICHT mehreren Nutzern, sondern wurde nur von einem hochgeladen. So ist auch in diesem Bezug die n:m Beziehung aus meiner Sicht nicht ganz rund.

            Sowas wie bug_project_id legt MySQL Workbench automatisch noch als Primarykey mit an, wenn man in wie in diesem Fall eine 1:n Relation zwischen bug & comment herstellt, da project_id neben id als Primarykey von bug eingetragen ist. Ob dies aus Performance Sicht Sinn macht oder Quatsch ist, kann ich nicht so gut bewerten. Ich weiß nur das MySQL Workbench zwischen identifizierenden (durchgezogene Linie) und nicht identifizierenden Relationen (gestrichelte Linie) unterscheidet. Bei den identifiziernden Relationen wird das verbindende Element als Primarykey gesetzt. Ich habe mir hier eine Art Frage gemerkt: Kann eine Entität dieser Tabelle ohne die Relation bestehen? Wenn nein, ist es eine identifizierende Relation. Beispiel: Ein Buch kann ohne ein Autor nicht existieren (identifizierende Relation). Ein Buch kann jedoch ohne Käufer existieren (nicht identifizierende Relation).

            Zitat von Arne Drews Beitrag anzeigen
            Hmmm... Gibt sicher unterschiedliche Ansätze, ich tendiere bei sowas zu Mapping-Tables.
            Am Beispiel von User:Media in etwa so:
            Code:
            // table: Users
            Id : auto_increment
            UserName : varchar
            
            // table: Media
            Id : auto_increment
            MediaPath : varchar
            MediaType : varchar
            MediaSize : decimal
            und dazu eben eine dritte Tabelle:
            Code:
            // table: UsersMediaMapping
            Id : auto_increment
            UserId : int
            MediaId : int
            Und das eben für die anderen Abhängigkeiten auch.
            Wie oben auch in der Antwort an lstegelitz: Macht dies denn Sinn bzw. ist dies zu empfehlen, wenn gar keine n:m Beziehung benötigt wird? Userid (Ersteller) zu Media 1:n. Media zu Userid 1:1 optional.

            Kommentar


            • #7
              Wenn ein User mehrere Medias haben kann, würde ich bei meiner Wahl bleiben. Du kannst es natürlich auch anders machen. Dein Ansatz ist ja aus meiner Sicht nicht falsch.
              Aber Du hast gefragt
              Competence-Center -> Enjoy the Informatrix
              PHProcks!Einsteiger freundliche Tutorials

              Kommentar


              • #8
                Zur User : Media , Media : User Relation
                Solche Referenzen sind erlaubt und ich finde es auch hier richtig abgebildet. Es ist etwas eine Frage der Details und der Constraints, die auf den Referenzen liegen und der Frage der Befülllung, also des Vorgehens wenn ein Medium oder Spezialfall ein Avatar als Medium eingetragen wird.
                Aus Constraint Sicht: Wenn nicht beide Referenzen befüllt sein müssen (das könnte (nur) bei user.media_id der Fall sein), wird zunächst das Medium angelegt mit Verweis auf User und fertig. Im 2. Schritt wird dann die Avatar Referenz eingetragen, fertig. 2 Schritte, gleich 1 Insert in Media, ein Update der User.Media_id
                Aus Transaktionssicht:
                2 Schritte müssen nicht sein, wenn beides in einer Transaktion ausgeführt wird.
                Datenbank Technik:
                Es gibt etwas, das nennt sich deferred constraint. Kann (oder konnte) mysql nicht, weiß ich nicht genau. Du scheiterst also vielleicht nur an den Fähigkeiten von mysql.

                Kommentar


                • #9
                  Hallo zusammen,

                  Zitat von Perry Staltic Beitrag anzeigen
                  Es gibt etwas, das nennt sich deferred constraint. Kann (oder konnte) mysql nicht, weiß ich nicht genau. Du scheiterst also vielleicht nur an den Fähigkeiten von mysql.
                  wenn ich es auf diesem Wege versuche und via phpMyAdmin in die xampp MariaDB importieren möchte, dann kommt, wie zu erwarten war folgende Fehlermeldung:

                  Code:
                  Can't create table `dbname`.`user` (Fehler: 150 "Foreign key constraint is incorrectly formed"). Referenced table `dbname`.`media` not found in the data dictionary near.
                  Sehe ich es richtig, dass ich entweder auf n:m Beziehungen zurückgreifen oder auf das Logging der Ersteller von Medien Dateien verzichten muss, wenn eine andere Datenbank nicht zur Verfügung steht?

                  Und dann wäre noch die Frage: Ist es aus eurer Sicht unproblematisch nicht benötigte Felder in n:m tables zu löschen? Beispiel bei der Tabelle bug_has_media das Löschen von bug_projekt_id?

                  Zitat von Arne Drews Beitrag anzeigen
                  Wenn ein User mehrere Medias haben kann, würde ich bei meiner Wahl bleiben. Du kannst es natürlich auch anders machen. Dein Ansatz ist ja aus meiner Sicht nicht falsch.
                  Aber Du hast gefragt
                  So habe ich es nun auch initial umgesetzt

                  Vielen Dank!

                  Kommentar


                  • #10
                    Zitat von Curcio Beitrag anzeigen
                    Code:
                    Can't create table `dbname`.`user` (Fehler: 150 "Foreign key constraint is incorrectly formed"). Referenced table `dbname`.`media` not found in the data dictionary near.
                    Sehe ich es richtig, dass ich entweder auf n:m Beziehungen zurückgreifen oder auf das Logging der Ersteller von Medien Dateien verzichten muss, wenn eine andere Datenbank nicht zur Verfügung steht?

                    Und dann wäre noch die Frage: Ist es aus eurer Sicht unproblematisch nicht benötigte Felder in n:m tables zu löschen? Beispiel bei der Tabelle bug_has_media das Löschen von bug_projekt_id?
                    Schwer zu sagen, in der Frage stecken mehrere Unbekannte. Das Bild ist schick, aber es sagt mir nicht so viel, wie eine konkrete Table Create Anweisung. Ebenso sagt das Wort "Import über.." nichts über Reihenfolgen, Feldbelegung, ..
                    Du hast eine konkrete Fehlermeldung geliefert, das macht nicht jeder, obwohl es naheliegend ist, alles andere bleibt leider unkonkret.
                    Ich arbeite nicht mit mysql, Du schon, also kannst Du einfach nachschlagen, ob Dein Create Statement (das bis jetzt nur Du kennst) von mysql akzeptiert wird.

                    Die 2. Frage verstehe ich nicht. Hast Du nicht geschrieben, das sei ein Übrungsmodel von Dir? Du kannst löschen was Du willst, selbst wenn es kein Übungsmodel ist.
                    Unbenutzte Felder sind nichts anderes als unbenutzte Tabellen oder Freiheitsgrade im Model, die nicht benötigt werden.
                    Ob Du einen Anwendungsfall hast, wo Du es mal vermissen wirst, kanst Du wohl nur alleine entscheiden.

                    Kommentar


                    • #11
                      Zitat von Perry Staltic Beitrag anzeigen
                      Schwer zu sagen, in der Frage stecken mehrere Unbekannte. Das Bild ist schick, aber es sagt mir nicht so viel, wie eine konkrete Table Create Anweisung. Ebenso sagt das Wort "Import über.." nichts über Reihenfolgen, Feldbelegung, ..
                      Du hast eine konkrete Fehlermeldung geliefert, das macht nicht jeder, obwohl es naheliegend ist, alles andere bleibt leider unkonkret.
                      Ich arbeite nicht mit mysql, Du schon, also kannst Du einfach nachschlagen, ob Dein Create Statement (das bis jetzt nur Du kennst) von mysql akzeptiert wird.
                      Hallo Perry, die Reihenfolge spielt hier ja eher weniger eine Rolle. Ich habe es auch mal im SQL Statement einfach gedreht. Aber die DB meckert auf der einen Seite halt, dass die user Tabelle noch nicht existiert und umgekehrt, wenn wir also mit der Erstellung der User Tabelle beginnen, wird die Media Tabelle vermisst. Man kann ja schlecht beide Tabellen gleichzeitig erstellen. Dies scheint MySQL jedoch zu erfordern, wenn man entsprechende Verweise aufeinander hat. Selbst wenn eines davon auch NULL sein kann.


                      Zitat von Perry Staltic Beitrag anzeigen
                      Die 2. Frage verstehe ich nicht. Hast Du nicht geschrieben, das sei ein Übrungsmodel von Dir? Du kannst löschen was Du willst, selbst wenn es kein Übungsmodel ist.
                      Unbenutzte Felder sind nichts anderes als unbenutzte Tabellen oder Freiheitsgrade im Model, die nicht benötigt werden.
                      Ob Du einen Anwendungsfall hast, wo Du es mal vermissen wirst, kanst Du wohl nur alleine entscheiden.
                      Die Frage zielt auf die Überlegung ab, welches Hintergrund es bei MySQL Workbench geben könnte, dass bei identifizierenden Beziehungen auch immer die anderen Feldattribute mitgeschleppt werden.


                      Der Primarykey von bug ist also nicht nur id, sondern auch project_id (da identifizierende Relation). Vermutlich macht MySQL Workbench dies also, um den zusammengesetzten Primarykey auch unter bug_has_media abzubilden. Meine Frage wäre also ist dies notwendig, sinnvoll oder aber reicht es nicht wenn hier ein identifizierendes Merkmal also bug_id verbleibt? Dies wäre also unabhängig von zukünftigen Anwendungsfällen eine rein theoretische Überlegung zum Sinn und Zweck dieser Felder in Punkto DBMS - darf man also in n:m Tabellen dann mehr oder weniger nur einen Teil des Primarykey über lassen und radikal nicht benötigte Felder löschen? Ich denke mir irgend einen Sinn wird es bei MySQL Workbench doch haben, dass man so genau zwischen identifizierenden Beziehungen und nicht identifizierenden Beziehungen unterscheidet und bei ersteren die verknüpfende ID des Elternelementes ebenso als Primarykey setzt?

                      Kommentar


                      • #12
                        Zitat von Curcio Beitrag anzeigen
                        Aber die DB meckert auf der einen Seite halt, dass die user Tabelle noch nicht existiert und umgekehrt, wenn wir also mit der Erstellung der User Tabelle beginnen, wird die Media Tabelle vermisst.

                        Dies wäre also unabhängig von zukünftigen Anwendungsfällen eine rein theoretische Überlegung zum Sinn und Zweck dieser Felder in Punkto DBMS - darf man also in n:m Tabellen dann mehr oder weniger nur einen Teil des Primarykey über lassen und radikal nicht benötigte Felder löschen?
                        Sorry, ich habe das ganz falsch verstanden. Ich war bei der Datenbefüllung.
                        Bei der Erzeugung und Benutzung von Datenmodellen bist Du nicht auf Workbench oder andere Produkte angewisen. Im Zweifel geht alles zu Fuß. In diesem Fall erzeugt man erst die Haupttabelle und die Untertabelle mit Referenz auf die Haupttabelle und am Ende ergänzt man als separate Anweisung den Key Constraint von Haupt auf Untertabelle. Wenn ein Tool nur komplette Table Create Statements ausspuckt, inkl. Ref Constraints kann es in solchen Fällen natürlich nicht funktionieren.
                        Ich könnte mir vorstellen, dass Workbench dafür irgendwo einen Schalter hat, der die DDL Statements gruppiert nach Typ ausgibt, erst die Tabellenrümpfe, meinetwegen mit PK, dann alle FK usw. . Ich nutze und kenn es aber nicht.
                        SQL an sich bietet meist die Möglichkeit, alles einzeln anzugeben.
                        Aber: Wenn Du die Tabellen entsprechend angelegt hast, kommt bei der Dateneingabe ein ähnliches Problem auf Dich zu durch die wechselseitigen Referenzen, davon habe ich ja schon geschrieben.

                        Wenn Du mehrspaltige PK hast, müssen wohl die FK auch mehrspaltig sein oder? Wenn Du eine bestimmte Dimension im Model nicht benötigst, dann kannst Du Sie aus dem Primär und allen Fremdschlüsseln entfernen. Häufig ist ja ein zusammengesetzter PK das Ergebnis einer N:M Zwischentabelle, das Entfernen eines Schlüsselteils bedeutet dann eigentlich auch, dass eine Tabelle mit rausfliegt (oder halt sinnlos, ungenutzt brachliegt)
                        Manchmal wählt man in einem Modell auch einen autarken PK aus einer Sequenz, obwohl die Schlüsseldefinition aus den FK auch reicht. Das ist dann redundant, aber bequem im Zugriff. Am ehesten vertretbar, wenn aus der bloßen N:M Relation auch noch eine Datenhaltung wird, also Attribute dazu kommen.

                        Kommentar

                        Lädt...
                        X