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:|