sicher ist das ein interessanter Ansatz, um Zustandsdaten-Stacks abzufragen. Aber in der Praxis wird er sich (außer es liegen nur einige wenige Werte vor) sehr schnell leider als unbrauchbar erweisen. Sicher mag das für die beschriebene Anwendung mit den paar Records dort reichen, aber die Aufgabe ist an ganz anderen Stellen noch sehr viel sinnvoller anwendbar.
Was mich gravierend daran stört ist, dass es an der falschen Stelle, eine Ebene zu spät, ansetzt. So etwas ist ureigenstes „Kerngeschäft“ eines Datenbanksystems selbst. Hier werden jedoch erstmal alle Daten ausgelesen, um sie dann DB-extern auszuwerten. Dabei werden dann wieder fast alle Werte letztlich weggeworfen, wenn z.B. nur nach dem „neuesten im Zeitraum“ gesucht wird. Das hat bei für DB normalen Größenordnungen fatale und völlig unnötige Laufzeitverzögerungen zur Folge. In SQL wäre das dagegen ein Einzeiler.
Weiterhin kommt hinzu, dass bei mehreren zeitgleichen RW-Prozessen überschneidende Effekte passieren werden, noch dazu bei solch stochastisch-eventgetriggerten Systemen wie es unser die reale Welt abbildendes IPS nun mal (zum Glück) ist. Durch das beschriebene Prinzip wäre hier aber die resultierende Datengüte sofort hinfällig.
Soetwas durch eingebaute Lock-Mechanismen intelligent zu handhaben, ist ebenfalls ureigenste Aufgabe eines DB-Systems selbst und sollte tunlichst dort verbleiben und genutzt werden, es sei denn, mann möchte das nochmal und hier dann auch noch 2 zeitgleich beteiligte Systeme/Ebenen beachtend (DB und PHP) neu aufbauen, was dagegen in Datenbanken über Jahrzehnte entwickelt und weltweit erprobt wurde.
Bleibt die Frage: Wie kann ich eigene Business Logic Layer in Form eigenen SQL-Codes zumindest in die Abfrage (besser: vollumfänglich, also inkl. Nutzbarkeit eigener SQL-Procedures, -Functions, -Triggers, -Views, -Typen usw.) der vorhandenen DB einbringen, oder muß ich die vorhandene DB-Schnittstelle mangels dessen leider auch weiter als nicht wirklich nutzbar (außer für ein paar eingebaute fest verdrahtete Visualisierungen) einstufen und mir weiterhin eigene DB-Schnittstellen zu eigenen daneben liegenden Datenbanken (aus)bauen?
Ich hatte eigentlich gehofft, dass sich da mitlerweile einiges getan hätte. Leider finde ich aber außer diesem Thread nichts in der Suche und gar nichts dazu in der Doku.
Vieleicht wäre dazu auch mal eine strategische Aussage aus der Chefetage möglich? Nur, damit man weiß, woran man ist und wo ansonsten eigene (Weiter)Entwicklungen angebracht sind. 
Danke, Gerd
