ERM vs Objektorientierung

character schrieb:
Ich denke mal dir wird fast jeder bestätigen, dass die Zend Engine kompletter Müll ist, selbst Refactoring hätte da keinen Sinn mehr. Man müsste diese eigentlich einmal von Grund auf neu entwickeln.

Ruheliebhaber schrieb:
In beiden Fällen hast Du das Problem, daß die Session verloren geht, da bei jedem Request fröhlich Server und Threads gewechselt werden.
Das ist ein generelles Problem von Anwendungen, die auf mehreren Webservern laufen. Aber im Endeffekt braucht man eine Session so oder so (CSRF-Tokens). Es kommt also nachher darauf an, wie man das Problem löst: Ein Proxy der die Anfrage immer zum richtigen Webserver leitet, ein gemeinsam genutzter Datenspeicher in dem die Daten liegen oder ein Sync-Protokoll für die Server.

Im Endeffekt ist die Lösung auf das Problem aber erstmal egal, denn es spielt aktuell einfach gar keine Rolle. Eine Proxy-Lösung passt zu jeder Anwendung, und die Speicherung von Sessions in einer Datenbank statt Dateien erfordert nur ein neu implementiertes SessionSaveHandlerInterface.
 
Ich finde, es spielt schon ein Rolle. Je nachdem, wo man in Zukunft mit der Anwendung hin will, macht es Sinn, sich darüber Gedanken zu machen, was man in der Session speichert und was nicht. Wenn mehrere tausend Zugriffe pro Minute den Server und die Datenbank lahm legen, gewinnen diese Dinge rasch an Bedeutung und die ursprüngliche Frage war, wie modelliere ich die Daten. Je weniger Abhängigkeiten zum Sessionhandling desto besser.

Im Endeffekt liegt die Entscheidung beim TE. Ich wollte nur einmal darauf hinweisen und zum Nachdenken anregen.
 
Solche Gedanken macht man sich, wenn man die Probleme hat oder garantiert weiß, dass sie kommen werden. Alles andere ist premature optimzation und macht die Software nur unwartbarer.
Hey wenn ich mehrere tausend Zugriffe pro Minute habe, könnte doch auch mein Rendering der Startseite ein Bottleneck sein, also muss ich das statisch Cachen! Aber eingeloggte User sollen für sie persönliche Infos bekommen, also brauche ich SSI und muss beim Include anhand des Vorhandenseins eines Session-Cookies unterscheiden. Und die Anwendung wird komplexer, komplexer und komplexer...

Und das ganze nachher für eine Anwendung, die von nichtmal 10 Personen gleichzeitig genutzt wird. Von der längeren und teureren Entwicklungszeit ganz zu schweigen.

Ich habe dutzende Projekte gesehen, bei denen die Entwickler Unmengen solcher Optimierungen eingebaut haben, und diese nachher gar nicht relevant waren. Und bei den Projekten, die doch erfolgreich waren, hat es dann an einer anderen Ecke gekracht, als man geplant hat.
 
Da gebe ich Dir vollkommen Recht. In allen Punkten.

Eine andere Erfahrung zeigt aber auch, daß "kleine Tools" länger leben, als man gedacht hat. Oder noch schlimmer. Der BWLer verlangt, daß der Prototyp zu einem richtigen Produkt ausgebaut wird und man alten Code natürlich nicht wegwerfen darf. So hat man später Designfehler in der Software, die das Produkt unwartbar machen.

Wie auch immer. Auch in der Softwareentwicklung muß man stets abwägen, was sinnvoll ist und was nicht. Wenn ich mit meinen Überlegungen über das Ziel hinaus geschossen bin, bitte ich um Entschuldigung.
 
Zurück
Oben