Werte in einem SET-Feld auswerten
Rolf
- datenbank
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
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
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
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
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
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
Hallo EKKi,
Schwierig ist das auch nicht -
stimmt:
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
Mahlzeit Rolf,
Schwierig ist das auch nicht -
stimmt:
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
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
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
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
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";