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