Ich plädiere für eine Datenbankrealisierung mit N:M Beziehungen und diversen Merkmalen. In dieser Form kann man jeden Pups definieren und natürlich wer mit wem.
Das sehe ich inzwischen auch so. Die ersten Jahre meiner Programmiererlaufbahn wollte ich auch immer alles im Programm implementieren, bis es irgendwann so komplext wurde, dass ich dort gescheitert bin. Dann musste ich mich (zwangläufig) mit einer Datenbanklösung auseinandersetzen und habe dann kapiert, wie genial einfach manches zu lösen ist, auch wenn die fachliche Komplexität extrem hoch ist.
Zumeist wird dann das Beziehungsgeflecht dann klarer.
Das Geflecht ist für mich kein Geflecht, sondern eine Matrix in der alle Kombinationen gegeneinander aufgeführt sind (notfalls je Produkt oder -Gruppe)
Ein Geflecht ist(oder wird) es dann, wenn man beginnt, diese Kreuzprodukt mit Regeln zu "vereinfachen".
Dies halte ich auch für richtig. Solange es noch ein Geflecht ist, ist es irgendwie nicht klar und man muss es besser formalisieren. Letztlich ist die Datenbank nichts weiters als die technische Vorhaltung des Inhaltes dieser Matrix.
Das ergibt evtl.,vielleicht eine schlankere Implementierung, am ehesten weniger Dateneingabeaufwand, aber der Teufel ist ein Eichhörnchen und die Marketingabteilung auch. Nahpets Schilderungen erinnern mich zumindest an solche Leute, die gefühlt immer mal wieder durchdrehen...
Bei uns war es ein Umfeld, dass auch mal zum Wort des Jahres deklariert wurde und ein paar Jahre später zum Unwort des Jahres. Die Praxisgebühr kam darin auch vor
Wer sich die dort anfallenden Regeln mal anschaut in Umfang und Komplexität, der hält das Problem hier (bei aller Komplexität) doch eher für "einfach". (Sorry, das ist jetzt nicht bös gemeint und soll auch niemanden herabwürdigen, Komplexität scheint mir ein durchaus subjektives Empfinden zu sein.) Und immer wieder der Rat: Aufmalen, aufschreiben, rein gedanklich kann kaum jemand so ein System auflösen und ein Design dafür erstellen. Ich weiß nicht, wieviele Quadrat(kilo)meter Tapeten wir für die Lösung von einzelnen Aufgaben gemalt haben, um irgendwie ein Bild vom (Teil)System zu bekommen.
Wie auch immer, wenn ich jede mögliche Kombi per "Klick" erlaube oder löschen kann, bin ich auf der sicheren Seite (und ich muss es nicht selbst machen, sondern die Marketingabteilung).
Dies halte ich für ein extrem wichtiges Argument für eine Datenbanklösung. Hier kann man eine Oberfläche bauen und die Entscheider, Fachleute, Marketingmenschen... können selbst einpflegen, was sie haben möchten und sind (
"sehr wichtig") auch für die Inhalte verantwortlich. Ist irgendeine Regel implementiert, so sind immer die Entwickler schuldig, egal wie unausgegoren, widersprüchlich, fehlerhaft... die fachliche Vorgabe war.
@Valle,
lass Dich jetzt bitte nicht von meinen Äußerungen verunsichern. Ich gehe davon aus, dass für eine Datenbanklösung bis zur Fertigstellung bei eurem System einige Mannmonate drauf gehen, selbst für das Datenbankdesign würde ich vermutlich einige Wochen brauchen. Aber wenn es dann einmal steht, habt ihr ein stabiles System, bei dem ihr nicht bei jedem Wunsch, jedem neuen Haus, jedem neuen Service, oder Katzen kosten jetzt auch was, Kaninchen aber nur die Hälfte... durch die Quelltexte müsst, um alle die Stellen zu lokalisieren, wo Änderungen erforderlich sind. Dies ist auf Dauer einfach zu fehleranfällig und macht Quelltexte irgendwann unbrauchbar. Das Redesign ist quasi schon vorprogrammiert.