Komplexe, zubuchbare Leistungen abstrahieren

[Sir Rufo]

[OT]
Ich dachte immer Sale wäre ein riesiger Konzern - geleitet von einem Herrn Sale -, dem alle Geschäfte gehören und dieses mehrfach im Jahr durch sein Logo zum Ausdruck bringen will.

Ein großer Mann, der Herr Sale
[/OT]

[Perlsau]

Zitat von Valle:

@Perlsau: Du beschreibst ja quasi nur eine einfache n:m Relation zwischen Ferienhäusern und Leistungen. Das hilft allerdings nicht viel, dann die Relation hilft mir nicht weiter, wenn Leistungen unter bestimmten Bedingungen angeboten werden können, die wiederrum von der Buchung abhängen. Auch ist die doch recht dynamische Berechnung des Preises damit nicht bewerkstelligt. Oder?

Ich hatte oben nicht alles beschrieben. So hatte ich z.B. einen Artikel-Verbund eingeführt, mit dessen Hilfe es möglich war, eventuell verfügbare Zusätze zu bestellen bzw. einen Artikel aus mehreren Einzelteilen zusammensetzen zu lassen. Beispiel: Der Kunde benötigt ein Regal mit 5 Brettern à 30 cm Tiefe und 200 cm Breite mit einer Stärke von 2 cm. Dazu benötigt er Stahlschienen und die zugehörigen Auflage-Winkel. Weiterhin benötigt er eine bestimmte Anzahl Dübel und Schrauben. Beim Bestellen wird, wenn nicht bereits vorhanden, ein neuer Artikel angelegt, der aus einem Artikelverbund besteht. Der heißt dann meinetwegen "Regal Press-200-30-2-5 Schien-weiß-lack-3 Schraub-10-6-6 Dübel-10-6-6". Benötigt ein weiterer Kunde genau dieses Regal, wird der bereits bestehende Artikelverbund verwendet. Im Artikelverbund stehen alle zum Gesamtartikel notwendigen Einzelteile (als Index), die ja dann bei dir z.B. "Zusatzreinigung" oder "Mittagessen" wären. Im Grundartikel muß zuvor verzeichnet werden, welche Zusatzleistungen für diesen Artikel (Hotelzimmer etc.) verfügbar sind und welche Bedingungen jeweils daran geknüpft sind. Ich gebe zu, das kann schon recht komplex werden. Du könntest aber z.B. ein Merkmal "Anreisetag" anlegen und die Verfügbarkeit weiterer Merkmale von einen bestimmten Anreisetag abhängig machen.

Du kannst dir ja mal bei der Firma Amirada (hab dort mal 4 Wochen gearbeitet) deren Katalogsystem anschauen. Deren Software ist in der Lage, jeden noch so komplexen Zusammenhang abzubilden. Intern arbeiten deren Module ebenfalls mit Merkmalen und Attributen (eine Unterkategorie der Merkmale). Dort habe ich dieses Prinzip auch kennengelernt.

Ich blende mich jetzt aber hier mal aus, weil ich doch den Eindruck habe, daß es für dein Problem bereits bessere Lösungen gibt und ich gerade auch ein wenig zu tun habe.

[mjustin]

Zitat von nahpets:

Durch Abfrage der von Dir gewünschten Bedingungen im Regelwerk kannst Du per SQL auf alle Wünsche eingehen. Eine derartige Logik im Quelltext abzubilden, halte ich nicht für sinnvoll, Du wirst irgendwann mit dem Ändern und Anpassen von Regeln und Ausnahmen nicht mehr nachkommen.
Über ein sinnvolles Datenbankdesign kannst Du mit implementierungstechnisch geringen Aufwand die kompliziertesten Regelwerke abbilden.

Zusammengefasst: "SQL > Delphi Code"

Das Ändern und Anpassen in der Datenbank ist einfacher als das ändern von Code? Es soll Unternehmen geben, in denen jede Änderung an der Datenbank eine Unterschrift der Geschäftsführung erfordert. Wird das Regelwerk nur einmal festgelegt und ändert sich nur alle Jubeljahre mal, dann mag das technisch und praktisch gehen. Das meinte ich mit "statisch" (im Sinne von "auch Glas ist eine Flüssigkeit"...).

In objektorientiertem Delphi Code, der auch problemlos durch Unit-Test abgesichert werden kann, halte ich Implementierung für deutlich flexibler. Wer mag und die Zeit hat, kann sich natürlich auch einen Generator für Tabellen und Abfragen programmieren, der in der Lage ist eine bestehende Datenbank sogar im laufenden Betrieb auf neue Regeln upzugraden

[nahpets]

Hallo Valle,

mir wird klar, wo Dein "Problem" liegt. Die Frage ist eigentlich nicht, ob man die Regeln in einer Datenbank ablegen kann, sondern wie man dort Bedingungen ablegen kann.

Vielleicht sollte ich mal dazusagen, dass ich regelmäßig per SQL SQL generiere und dann ausführe. Zumindest bei Oracle klappt das hervoragend.

Wir haben mal ein System erstellen müssen, in dem es dutzende von Tabellen gab, in denen sehr variable Bedingungen abzulegen waren. Wir haben das in der Form gelöst, dass in den Tabellen quasi Teile der zu erstellenden Datenbankabfragen enthalten waren, aber so, dass nicht SQL-kundiges Personal in der Lage war, diese Bedingungen zu pflegen. Aus den Inhalten dieser Tabellen wurden dann zur Laufzeit per SQL SQL-Statements (bzw. die Wherebedingungen) generiert und dann ausgeführt. Das Ergebnis der so erstellten Abfragen wurde dann von Datenbankpackages oder Programmen weiterverarbeitet. Teils zur Befüllung neuer Tabellen oder zur Ausgabe von Listen, XML-Dateien... Wäre ein derartiges Vorgehen für euch eine Option?

Ein Beispiel:

Code:

Ferienhaus   Ding          Tage Preis   ProPerson ProNacht
Ferienhaus 1 Zimmerservice >5   0,00€   -         -
Ferienhaus 1 W-LAN         =1   2,00€   -         ja
Ferienhaus 1 Frühstück     =1   4,50€   ja        ja
Ferienhaus 2 Zimmerservice >7   15,00€  -         -
Ferienhaus 3 Zimmerservice =0   0,00€   -         -
Ferienhaus 3 Hund          =1   15,00€  -         -
Ferienhaus 4 Zimmerservice =7   0,00€   -         -
Ferienhaus 4 Hund          >2   7,50€   -         -
Ferienhaus 5 Zimmerservice =7   2,00€   ja        -
Ferienhaus 5 Hund          =1   0,50€   -         ja

Das soll jetzt heißen: Beim Ferienhaus 1 gibt es den Zimmerservice kostenlos dazu, wenn das Ferienhaus über 5 Tage gebucht wurde, bei Ferienhaus 2, wenn mehr als 7 Tage gebucht wurde. Im Ferienhaus 3 gibt es keinen Zimmmerservice, ein Hund kostet insgesamt grundsätzlich 15 €. Im Ferienhaus 1 kostet das W-LAN pro Übernachtung 2,00 € und pro Person kann man pro Übernachtung für 4,50 € ein Frühstück erhalten.
Im Ferienhaus 4 gibt es alle 7 Tage einen kostenlosen Zimmerservice. Diese Leistung ist auch im Ferienhaus 5 verfügbar, dort kostet sie aber pro Person 2,00 €.
Im Ferienhaus 4 kostet ein Hund bei einem Aufenthalt über 2 Tage pauschal 7,50 €, während im Ferienhaus 5 ein Hund pro Übernachtung 0,50 € kostet.

Ergibt dies eine Vorstellung von dem, was ich meine?

Code:

Im Geamtpreis sind enthalten:
# if ferienhaus.id in (42, 21, 33, 34, 45, 75, 23, 22):
# if (buchung.bis - buchung.von) > 5:
eine Zwischenreinigung
# elseif (buchung.bis - buchung.von) > 10:
zwei Zwischenreinigungen
# endif
# elseif ferienhaus.id in (102, 54, 101):

Das kommt eigentlich sehr nah an meine Vorstellungen heran, nur würde ich versuchen dies per SQL abzubilden. Die FerienhausID würden wir in meinem Beispiel oben ja wiederfinden, Ferienhaus 1 steht dort ja nur der besseren Lesbarkeit wegen, in der DB wäre es der technische Schlüssel, ebenso bei den "Dingen". Wenn wir nun per SQL auf die Tabelle oben zugreifen, so finden wir den Wert > 5, die Zeitdifferenz zwischen buchung.von und buchung.bis können wir auch per SQL errechnen, kombiniert mit dem gefundenen > 5 ist also auch diese Bedingung gefunden und der Preis berechenbar.

Die Hürde, vor der Du stehst ist mir klar geworden. Ad hoc kann ich Dir jetzt auch nicht sagen, wie man das in eine Datenbank legt, dazu müsste man tatsächlich zuerst einmal einen möglichst vollständigen Überblick über die Regeln haben, um dann eine passende Struktur zu finden und zu entscheiden, wieviele Tabellen in welcher Struktur erforderlich werden. Klar ist aber auch, dass die Implementierung all dieser Regeln nur im Quelltext, egal ob ein Plugin oder n, erheblichen Aufwand bereiten wird und die Pflege extrem hoch werden kann.

Solche Regeln darf es im Programmcode nicht geben:

Code:

if ferienhaus.id in (42, 21, 33, 34, 45, 75, 23, 22):

Hier muss irgendeine Datenbasis herangezogen werden, so dass die Programmlogik sich auf die Berechnung für ein konkretes Ferienhaus beziehen kann.

Ist es möglich für 2 oder 3 Ferienhäuser einmal eine (Excel)-Tabelle zu erstellen, in der alle Regeln ausformuliert dargestellt sind?

Der Screenshot zeigt eigentlich genau das, was ich mir auch vorgestellt habe, beim Design scheinen die Vorstellungen nicht weit auseinander zu liegen.

Perlsau beschreibt eigentlich mit seinen Worten sehr genau das, was ich meine. Momentan gehe ich noch davon aus, dass eine Datenbanklösung für euer System im Rahmen des Möglichen ist.

Zitat von mjustin:

Das Ändern und Anpassen in der Datenbank ist einfacher als das ändern von Code?

Ja natürlich. Tabelleninhalt ändern, commit und die Regel funktioniert. Kein neues Kompilieren, kein neues Testen, keine neue Auslieferung eines Programmes.

Zitat von mjustin:

In objektorientiertem Delphi Code, der auch problemlos durch Unit-Test abgesichert werden kann, halte ich Implementierung für deutlich flexibler. Wer mag und die Zeit hat, kann sich natürlich auch einen Generator für Tabellen und Abfragen programmieren, der in der Lage ist eine bestehende Datenbank sogar im laufenden Betrieb auf neue Regeln upzugraden

Aus genau diesem Grund haben wir ein System auf die Steuerung durch Datenbanktabellen umgestellt, weil wir mit dem Einpflegen der Änderungen in den Programmcode nicht mehr nachkamen. Die Änderungen kamen schneller, als wir die Programme, Bibliotheken... ändern, testen und ausliefern konnten. Offensichtlich haben wir aber auch sehr unterschiedliche Ansichten davon, was ein Regelwerk ist. Du siehst darin (vermutlich) eine einmalige Sammlung mehr oder weniger aufwändiger Regelungen, die dann aber für "immer" bestand haben. Hier in dem Beispiel von Valle gehe ich aber davon aus, dass sich die Regel pro Ferienhaus, pro Saison... sehr flexibel und häufig ändern können. Jederzeit können neue Ferienhäuser hinzukommen oder wegfallen. Optionen hinzukommen oder wegfallen. Von einem statischen System dürfen wir hier wohl kaum ausgehen. Und wenn in dem Unternehem dann für jede Änderung, jedes neue Ferienhaus... eine Unterschrift der Geschäftsführung zwecks Erlaubnis zur Änderung der Regel erforderlich sein sollte, dann liefe da was grundlegend falsch.

@generic: Ich weiß seit ca. 50 Jahren, dass ich nicht richtig schreiben kann. Dafür stehen meine Schreibfehler unter der GPL und können von allen kostenlos jederzeit beliebig häufig genutzt werden.
English schreibt man im Deutschen übrigens mit sch.
Spar Dir bitte solche Belehrungen, sie sind für die Problemlösung nicht zielführend und zum Glück machst Du ja keine Schreibfehler

[p80286]

Um das Beispiel von Stephan aufzugreifen
Du hast folgende Reinigungsvorgänge
nach 3 Tagen
nach 7 Tagen
alle 10 Tage
Endreinigung

Diese verknüpst du über Normleistung mit den Wohnungen, das ist dann die Leistung die nicht extra berechnet wird.
Weiterhin hast Du die Tabelle Zusatzleistung in der mögliche Zusatzreinigungen für die Wohnungen aufgeführt werden:

WohnID LeistungID Zuzahlung Buchungsbegin BuchungsdauerMin BuchungsdauerMax entfallendeNormLeistungID

GGf müsstest Du eine weitere Tabelle mit entfallenden Leistungen einführen. Das kommt aber darauf an, wie komplex das entsprechende Beziehungsgepflecht ist.

Auf jeden Fall kommst Du nicht mit 3 oder 4 Tabellen hin, und den Vorschlag einmal tabellarisch die verschieden Bedingungen auszuformulieren kann ich nur unterstützen. Zumeist wird dann das Beziehungsgeflecht dann klarer.

Gruß
K-H

Gruß
K-H

[jobo]

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.

Zitat von p80286:

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, ..)

[nahpets]

Zitat von jobo:

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.

Zitat von jobo:

Zitat von p80286:

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.

Zitat von jobo:

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.

Zitat von jobo:

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.

[Namenloser]

Ich finde, die eigentliche „Komplexität“ liegt hier in der geforderten Flexibilität. Bei irgendwelchem Praxisgebühr-Kram, gibt es, nehme ich an, einheitliche, gesetzliche Regelungen, die sich auch höchstens alle paar Jahre mal ändern. Bei Valle ist es eher so, als ob jede Praxis ihre eigenen Gesetze hätte...

Aber ich finde es interessant, wie es hier anscheinend zwei Lager gibt.

[Valle]

Hallo,

ich habe jetzt nochmal nachgehakt und noch eine ganze Menge weiterer Leistungen als Liste bekommen. Alles in allem ist die Menge an Bedingungen kaum weiter gestiegen und es handelt sich nach wie vor um die Variablen "maximal buchbare Menge" und "Preis" die individuell berechnet werden müssen. Die Liste ist hier vermutlich nicht wirklich hilfreich. Es kamen Dinge hinzu wie Heizung, Brennholz, Kinderspielzeug, Geburtstagskuchen, Fahrradverleih usw.

@nahpets: Die Option SQL Statements in die Datenbank zu speichern klingt sehr spannend. Allerdings wird das technisch ein kleines Problem, da wir ausschließlich über einen ORM (SQLAlchemy) mit der Datenbank kommunzieren. Dieser mag sowas leider überhaupt nicht. Deine Beispieltabelle überzeugt auf den ersten Blick mit ihrer Einfachheit, ist aber bei genauerer Betrachtung wahrscheinlich nicht flexibel genug. Maximal zubuchbare Betten würden ein Problem geben und die Menge an Bedingungsspalten könnte immer weiter wachsen.

Wenn ich keinen SQL Code dynamisch erzeugen kann, dann muss ich doch davon ausgehen, dass sich beim Hinzufügen weiterer Leistungen mit bestimmten Bedingungen weitere Logiken hinzufügen muss. Und da diese auf jeden Fall irgendwie programmiert werden müssen, egal ob in SQL oder Python, kommt man um eine von Programmierer herbeigeführte Änderung der Datenbank oder des Codes nicht herum. Also heißt das für mich, dass wir sowieso damit beschäftigt sein werden, bei neuen Leistungen auch neue Bedingungen und Preis-Algorithmen zu entwickeln. Wo das geschieht, kann uns als Entwickler im Prinzip dann ja egal sein. Da sich der SQL-Option aber aus technischen Gründen nicht wirklich anbietet, ist Code m.E. hier einfacher.

Daher überlege ich im Moment an einer Mischung aus beiden Systemen. Weiterhin sind Ferienhäuser mit Leistungen über eine n:m-Relation verknüpft. Jeder Verknüpfung sind allerdings noch je ein oder mehrere weitere Einträge aus zwei weiteren Tabellen zugeordnet. Eine Verknüpfung der Zusatzleistung "Baby Hochstühle" mit dem Ferienhaus X enthält außerdem einen Fremdschlüssel in eine Tabelle mit allen möglichen "Preis-Berechnungs"-Plugins. Außerdem eine weitere n:m-Relation zu einer Tabelle mit allen "Maximal buchbare Menge"-Plugins. Im Anhang ist ein Diagramm wie ich mir das vorstelle.

Die Preis-Tabelle hält sich nach aktuellen Kenntnisstand noch klein mit 4 Plugins für alle Permutationen von "pro Nacht" und "pro Person". Die Tabelle mit den Berechnungs-Plugins für maximal buchbare Menge enthält Plugins wie "nur im Winter" oder "maximal so viel wie Babys eingebucht". Da mehrere Plugins verknüpft werden können, gewinnt immer das Plugin mit der niedrigsten Mengenangabe. Maximalmenge wäre im Sommer dann eben 0, wenn "nur so viel Holz wie Nächte" zwar 7 sagt, aber "Holz nur im Winter" eben 0.

Für jedes dieser Plugins existiert eine sehr einfache Klasse im Code. Eigentlich reicht schon fast eine Funktion. Natürlich muss dieser dann auch mal geändert werden. Allerdings müssen wir die Software ja an keine Kunden ausrollen, da wir die Software ausschließlich für uns verwenden. Wie ich finde, hat man damit die höchste Flexibilität bei geringstem Aufwand.

Man könnte diese Plugins statt im Code auch in SQL realisieren. Allerdings sehe ich hier keinen Vorteil. Wir müssten erstmal unseren ORM davon überzeugen die zu verwenden. Und wo besteht für mich der Unterschied, ob ich SQL (z.B. Stored Procedures) oder Python entwickeln muss, wenn $chef was Neuen will?

@NamenLozer: Ich finde die Diskussion auch recht interessant. Ich war bisher der Meinung, dass eine Datenbank hauptsächlich zuständig ist um Daten zu speichern, zu verwalten, aufzubereiten und herauszusuchen. Berechnungen von Verfügbarkeit und Preisen ist m.E. Logik, die eigentluch nicht in die Datenbank gehört. Die Frage ist allerdings, was einfacher ist. Ich kann mir schon vorstellen, dass größere Firmen sinnvollerweise da ganz andere Herangehensweisen haben.

Ich freue mich auf eure Meinungen dazu und lasse mich auch gern verunsichern; denn dazu bin ich hier; sonst würde ich nicht fragen.

Liebe Grüße,
Valentin

[jobo]

Zitat von Valle:

@NamenLozer: Ich finde die Diskussion auch recht interessant. Ich war bisher der Meinung, dass eine Datenbank hauptsächlich zuständig ist um Daten zu speichern, zu verwalten, aufzubereiten und herauszusuchen. Berechnungen von Verfügbarkeit und Preisen ist m.E. Logik, die eigentluch nicht in die Datenbank gehört. Die Frage ist allerdings, was einfacher ist. Ich kann mir schon vorstellen, dass größere Firmen sinnvollerweise da ganz andere Herangehensweisen haben.

Also die Frage, wo die (Business-)Logik liegt, ist ebenfalls spannend, aber hier nicht der Kern.
Die Diskussion dreht sich m.E. darum, ob ich ein Regelwerk implementiere oder "ganz billig" Fall für Fall bzw. gültige Kombinationen definiere(!).
Daraus ergeben sich unterschiedliche Implikationen für Änderungen, Erweiterungen und auch Korrektheit.
Eine DB Matrix kann jederzeit durch neue Datensätze in x/y Richtung erweitert werden, also neue Merkmale, ebenso kann durch Definition neuer N:M Relationen jederzeit die Merkmalskombination verändert werden. Das ist Insert/Update/Delete von Zahlen (ID) und Merkmalstexten.
Regeln dagegen müssen durch Spezialisten durchdacht, geschaffen und deployed werden.