Hi,
Programmlogik und Daten sollten grundsätzlich getrennt werden.
Ja.
Gut begründete Abweichungen von dieser Maxime sind natürlich denkbar (wie bei allen anderen Maximen auch).
Eben.
Dann wäre aber zu überlegen, wie man das Ganze gegen das erwähnte "Vergessen" von Änderungen und ähnliche Fehlerquellen absichert, welche Schritte bei einer Änderung zu dokumentieren sind, um eben "Vergessen" weitgehend ausschliessen zu können, etc.
Dokumentieren ist wichtig, schon klar.
Mit Ressourcen allzu verschwenderisch umzugehen, ist trotzdem nicht angebracht.
Das beruhigt mich, d. h. vollkommen überholt ist mein Gedankengang nicht.
Gerade bei komplexeren Berechnungen, deren Ergebnisse "statisch" bleiben, so lange sich auch die Eingabedaten nicht ändern, ist ein "Caching" der Ergebnisse natürlich oftmals sinnvoll.
Das einzige, was man noch tun könnte, unnötige Datenbankabfragen zu vermeiden, ist, Inhalte, die mehrfach verwendet werden oder die womöglich irgendwann geändert werden müssen, in einer inkludierten Datei abzulegen.
Das kann man ja zu einem Kompromiss kombinieren.
Die eigentlichen Daten werden in der Datenbank vorgehalten, und auch dort ggf. geändert.
Von diesen zieht man dann ein "Abbild" - im PHP-Umfeld könnte das bspw. eine entsprechend serialisierte, oder auch gleich als parse-barer Code in einer Include-Datei abgelegte Datenstruktur sein - die wird einfach eingebunden, und steht sofort zur Verfügung.
Natürlich muss dieses Include dann neu generiert werden, wenn sich die Daten auf der Datenbank ändern. Auch hier ist wieder zu überlegen, wie man das verlässlich triggern kann.
Genauso dachte ich mir das.
Deshalb würde ich gern mal wissen, ob Ihr auch solche Überlegungen anstellt, oder aus ökonomischen Gründen auf maximale Wartbarkeit Wert legt, sprich alles in einer Datenbank ablegt, egal ob das zusätzliche, unnötige Datenbankabfragen bedeutet.
Wenn man mehrere Faktoren zu berücksichtigen hat, welche die Gesamteffizienz eines Systems in unterschiedliche Richtungen beeinflussen, dann wird man in aller Regel nicht in einer bestimmten Hinsicht "optimieren", weil das sich auf die anderen Faktoren ungünstig auswirkt - sondern auch hier einen Kompromiss suchen, der alle Faktoren möglichst ausgewogen berücksichtigt, um ein stimmiges Gesamtbild zu erhalten.
Eine Applikation, die von einem Vierjährigen zu warten wäre, aber in Punkto Performance und Bedienbarkeit durch den Endanwender stark zu wünschen übrig lässt, ist genauso ein Rohrkrepierer, wie eine mit der einfachsten und effizientesten Datenhaltung, die aber nur von einem Spezialisten gewartet werden kann, der selbst für die Übersetzung der Textausgabe "hello world" in eine andere Sprache fünf Tage lang ins System eintauchen muss ...
gruß,
wahsaga
Ich ziehe daraus die Erkenntnis, man sollte einen Kompromiß, der Performance und Wartbarkeit unter Einbeziehung der Applikationsanforderungen optimal vereint, schließen.
Früher war das ganz anders. Funktionen, die sich während des Programmablaufs selbst verändern, waren da ganz normal. Da wurde jeder Taktzyklus genau durchgerechnet. Da wäre es einfach undenkbar gewesen, Zugeständnisse in Richtung Lesbarkeit oder Wartbarkeit des Codes zu machen. Das genaue Gegenteil von OOP heute.
Gruß
Th.