Rolf: Werte in einem SET-Feld auswerten

Hallo,

in einer MySQL-Tabelle stehen Objekte, die Kategorien zugeordnet werden.
Da ein Objekt in mehreren Kategorien vertreten sein darf, wurde als Feldtyp "SET" gewählt.
In einer weiteren Tabelle sind die zulässigen Kategorien enthalten, derzeit 6, also weit unter der Grenze von 64.

Leider habe ich Probleme bei der Formulierung folgender Abfrage:
"Zeige für jede Kategorie die Anzahl der vorhandenen Objekte.
 Objekte in mehreren Kategorien sollen mehrfach gezählt werden!"
Dabei sollte sowas hier herauskommen:
oID - Objekt-ID
cID - Kategorie-ID
+-----+-----+
| oID | cID |
+-----+-----+
|  1  | 1,3 |
|  2  | 3,5 |
|  3  | 3   |
|  4  | 1   |
|  5  | 5   |
|  6  | 1,3 |
|  7  | 1,5 |
|  8  | 1   |
|  9  | 3   |
+-----+-----+
geforderter Result:
+-----+---------+
| cID | count() |
+-----+---------+
|  1  |     5   |
|  3  |     5   |
|  5  |     3   |
+-----+---------+
Obwohl also nur 9 Objekte vorhanden sind, werden 13 gezählt,
weil 4 Objekte in zwei Kategorien vorkommen - verständlich?

Hoffe auf zielführende Hinweise ...

m.b.G. Rolf

  1. Hi Rolf,

    Hoffe auf zielführende Hinweise ...

    Dein Datenbank~/Tabellendesign ist Muell.

    +-----+-----+
    | oID | cID |
    +-----+-----+
    |  1  | 1,3 |
            ^^^^^   sowas macht man nicht

    es sollte besser so aussehen

    +-----+-----+
    | oID | cID |
    +-----+-----+
    |  1   | 1    |
    |  1   | 3    |

    Ciao, Frank

    1. Hi no.reg. Frank,

      Dein Datenbank~/Tabellendesign ist Muell.

      super, dann passt es zu Deiner Ausdrucksweise ... ;-)

      es sollte besser so aussehen
      +-----+-----+
      | oID | cID |
      +-----+-----+
      |  1  | 1   |
      |  1  | 3   |

      dann hätte ich ja Unmengen von Dubletten!
      Was soll daran besser sein ... :-((

      m.b.G. Rolf

      1. Mahlzeit Rolf,

        Dein Datenbank~/Tabellendesign ist Muell.
        super, dann passt es zu Deiner Ausdrucksweise ... ;-)

        Das ändert aber nichts daran, dass er Recht hat.

        es sollte besser so aussehen
        +-----+-----+
        | oID | cID |
        +-----+-----+
        |  1  | 1   |
        |  1  | 3   |
        dann hätte ich ja Unmengen von Dubletten!

        Nein, Stichwort Normalisierung. Wo siehst Du da Dubletten? Für jede eindeutige oID-cID-Kombination gibt es genau einen Eintrag in der Zuordnungstabelle. n:m-Beziehungen bildet man sinnvollerweise so ab.

        Was soll daran besser sein ... :-((

        Alles. Informiere Dich.

        MfG,
        EKKi

        --
        sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
        1. Hi EKKi,

          Für jede eindeutige oID-cID-Kombination gibt es genau einen Eintrag in der Zuordnungstabelle.

          so hatten wir es vorher!

          Quizz:
          Kennst Du für normalisierte Tabellen ein DAU-likes Pflegetool?
          Ich nicht!
          Deshalb wurde die Zuordnungstabelle gegen das SET getauscht.

          m.b.G. Rolf

          1. Mahlzeit Rolf,

            Quizz:
            Kennst Du für normalisierte Tabellen ein DAU-likes Pflegetool?

            Ja. Es wäre z.B. möglich, auch wenn die Datenbanktabelle so aussehen

            ID | foo
            ---+------
             1 | fasel
            18 | laber
            32 | blubb

            ID | bar
            ---+----
             4 | dödel
             7 | didel
            16 | dei
            28 | didumm

            foo_ID | bar_ID
            -------+-------
                 1 |     4
                 1 |    16
                32 |     7
                18 |    28
                18 |    16

            es an der Oberfläche so darzustellen

            Aktion       | foo   | bar
            -------------+-------+-----------
            [Bearbeiten] | fasel | dödel, dei
            [Bearbeiten] | blubb | didel
            [Bearbeiten] | laber | dei, didumm

            und beim Klick auf "Bearbeiten" wird ein Formular angezeigt mit einer entsprechenden <select>-Box mit gesetztem "http://de.selfhtml.org/html/formulare/auswahl.htm#listen_mehrfach@title=multiple"-Attribut.

            Schwierig ist das auch nicht - nur ein wenig Bastelarbeit (wenn man kein entsprechendes Framework hat) ...

            Ich nicht!
            Deshalb wurde die Zuordnungstabelle gegen das SET getauscht.

            Es ist absoluter Schwachsinn, nur weil an der Oberfläche irgendwas irgendwie dargestellt werden soll oder weil die Benutzer Probleme haben, die darunter liegenden Datenstrukturen grundlegend kaputtzumachen.

            MfG,
            EKKi

            --
            sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
            1. Hallo EKKi,

              Schwierig ist das auch nicht -

              stimmt:
               aktuelle Lösung

              wenn man kein entsprechendes Framework hat ...

              zeige mir bitte nur eines, würde mir schon reichen ... ;-)

              Es ist absoluter Schwachsinn, ... f.f.

              was glaubst Du mit solchen ausfallenden Statements zu erreichen?
              Reife, Kompetenz, Ansehen, Achtung ... ;-)
              Ob Deine Aussage stimmt wird, ohne Nachzuprüfung, niemand glauben,
              und die, die es wissen müssten, lesen solche Beiträge erst gar nicht.

              m.b.G. Rolf

              1. Mahlzeit Rolf,

                Schwierig ist das auch nicht -
                stimmt:
                 aktuelle Lösung

                Natürlich kann man das auch mit Checkboxen machen (Du meintest doch die "Kategorien" ganz oben in dem Formular?) - klar. Das betrifft aber immer nur die DARSTELLUNG, die darunterliegende Datenstruktur sollte trotzdem sinnvoll sein ... und das ist Deine in keinster Weise.

                wenn man kein entsprechendes Framework hat ...
                zeige mir bitte nur eines, würde mir schon reichen ... ;-)

                Ich habe sowas (ähnliches) bereits mehrfach in verschiedenen Projekten ge-/verbaut, sooo schwierig kann's also nicht sein. Waren aber nie öffentlich verfügbare.

                Es ist absoluter Schwachsinn, ... f.f.
                was glaubst Du mit solchen ausfallenden Statements zu erreichen?

                Ausfallend? Es IST nicht sinnvoll, bestehende vernünftige Datenstrukturen (Stichwort Normalisierung) aufgrund der DARSTELLUNG zu zerstören und stattdessen Datenmüll zu produzieren. Glaub es oder lass es, es bleibt dabei. Ich habe nicht gesagt, dass Du schwachsinnig bist. Ich habe gesagt, dass das Datenmodell bzw. die Vorgehensweise schwachsinnig ist.

                Ob Deine Aussage stimmt wird, ohne Nachzuprüfung, niemand glauben,
                und die, die es wissen müssten, lesen solche Beiträge erst gar nicht.

                Sie stimmt.

                MfG,
                EKKi

                --
                sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
                1. Hallo EKKi,

                  Das betrifft aber immer nur die DARSTELLUNG,

                  stimmt!

                  die darunterliegende Datenstruktur sollte trotzdem sinnvoll sein ...

                  unbedingt!
                  Aber wenn mit dem FeldTyp "SET" keine brauchbaren Abfragen erstellt werden können,
                  ist seine Existenzberechtigung zumindestens fragwürdig.
                  Ansonsten ist es gelungen Objekt- und Zuordnungstabelle über EIN Formular/Script zu pflegen.

                  und das ist Deine in keinster Weise.

                  Du bist nicht flexibel!
                  Deine Behauptung bezieht sich auf den OP und der ist schon angeschimmelt.
                  Oder glaubst Du ich sitze hier rum und warte nur auf Eingebungen ... ;-)
                  Merke:
                  Ein Problem in ein Forum zu stellen hat in 9 von 10 Fällen den Zweck, Druck abzubauen,
                  man hat ja gefragt. Und solcherart "entlastet" kommen wieder vernünftige Einfälle,
                  völlig unabhängig von den Antworten im Forum.

                  wenn man kein entsprechendes Framework hat ...
                  zeige mir bitte nur eines, würde mir schon reichen ... ;-)
                  Waren aber nie öffentlich verfügbare.

                  q.e.d.

                  Sie stimmt.

                  reine Schutzbehauptung ... ;-))

                  m.b.G. Rolf

                  1. Rolf,

                    wenn du sowie alles besser weisst, warum belaestigst du uns dann mit deinen Problemen?

                    Mit deiner Art machst du dir hier nicht gerade Freunde und sicher werde ich mir ueberlegen, ob ich das naechste Mal einen Hinweis geben werde.

                    Und tschuess
                    Frank

                  2. Mahlzeit Rolf,

                    Aber wenn mit dem FeldTyp "SET" keine brauchbaren Abfragen erstellt werden können,
                    ist seine Existenzberechtigung zumindestens fragwürdig.

                    Nein, ist sie nicht. Sicher kann es in anderen Anwendungsfällen sinnvoll sein, SET einzusetzen. Wenn die dort drinnen gespeicherten Werte aber u.U. als WHERE-Kriterium dienen sollen, sollte man berücksichtigen, dass kein einziger Index diese Werte benutzen kann und immer ein Full-Table-Scan notwendig ist - und das ist im Sinne eines performanten rDBMS eigentlich untragbar ... wenn man jetzt einmal davon absieht, dass das Tabellendesign noch nicht einmal der ersten Normalform entspricht und dadurch eigentlich schon per definitionem defekt ist.

                    Ansonsten ist es gelungen Objekt- und Zuordnungstabelle über EIN Formular/Script zu pflegen.

                    Nochmal: einziges und alleiniges Kriterium ist die Art und Weise der Datenspeicherung bzw. die Beziehungen der Daten untereinander. Ob man nur ein Formular bzw. Skript zur Pflege braucht oder nicht, ist absolut irrelevant für ein sinnvolles Datenbankdesign.

                    Du bist nicht flexibel!
                    Deine Behauptung bezieht sich auf den OP und der ist schon angeschimmelt.

                    Achja? Ich kann in keinem Deiner Folgepostings erkennen, dass Du die Kritik ernst genommen und darauf angemessen reagiert hast. Insofern ist das Datenbankdesign, das Du dort angegeben hast, anscheinend immer noch existent - und damit immer noch kaputt.

                    wenn man kein entsprechendes Framework hat ...
                    zeige mir bitte nur eines, würde mir schon reichen ... ;-)
                    Waren aber nie öffentlich verfügbare.
                    q.e.d.

                    Bitte? Was soll das denn bedeuten? Nur weil ich urheberrechtlich geschützten Code hier nicht veröffentliche, heißt das noch lange nicht, dass es keine trivialen Lösungen für das Problem der Datenpflege von n:m-Beziehungen gibt.

                    Sie stimmt.
                    reine Schutzbehauptung ... ;-))

                    Wenn Du der Meinung bist ... dann werd glücklich mit Deinem Schrott - aber jammere nicht, dass es nicht funktioniert.

                    MfG,
                    EKKi

                    --
                    sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
  2. echo $begrüßung;

    [ein SET]
    "Zeige für jede Kategorie die Anzahl der vorhandenen Objekte.

    Für einzelne Werte kannst du die betroffenenn Datensätze mit FIND_IN_SET() ermitteln. Ich wüsste aber nicht, wie man darüber gruppieren könnte. Es müssten dabei ja beispielsweise zwei Einträge in der Ergebnismenge entstehen, wenn im SET zwei Werte stehen, damit diese für die unterschiedlichen cID gezählt werden können. Irgendeine Von-hinten-durch-die-Brust-Lösung wird es sicher geben, aber einfacher kämst du zu einer Lösung mit der von Frank vorgeschlagenen 1:n-Abbildung.

    echo "$verabschiedung $name";