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.
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".
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...
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).
In den Relationen kann man Einzelpreise, Inklusivpreise, (Mengen)rabatte usw. einbinden und regeln, ob das (Standard-)Produkt oder die aktuellste Rabatt-Option gewinnt.
Dynamische Varianten wären durch Min/Max Person oder Min/Max Dauer Bereichsangaben zu realisieren.
Wenn man Komfort bieten möchte (für Selektion und Definition der Merkmale) kann man diese noch mit Klassen versehen (ala Reinigung, Kinder, Haustiere, Lieferservice, Langzeit, ..)