SQL-Klasse in Session speichern

[Patrik]

Hallo.

Eine SQL-Klasse in der Session zu speichern.. ist das
vollkommener Schwachsinn oder Gang und Gebe?
Oder gibt es Alternativen hinsichtlich Globalisierung der
SQL-Klasse, so dass ich sie nicht in jeder anderen Klasse
erneut instanziieren, oder sie ständig übergeben muss?

Wie händelt Ihr so etwas?

Thx & Grüße aus Berlin
 Patrik

[Ludger]

Hi,

Eine SQL-Klasse in der Session zu speichern.. ist das
vollkommener Schwachsinn oder Gang und Gebe?

vermutlich ist das aeusserst ungewoehnlich. Was ist uebrigens genau eine "SQL-Klasse"?

Oder gibt es Alternativen hinsichtlich Globalisierung der
SQL-Klasse, so dass ich sie nicht in jeder anderen Klasse
erneut instanziieren, oder sie ständig übergeben muss?

Du hast einen objektorientierten Datenzugriff entwickelt, also bspw. kommt ein parametrisiertes Tabellenobjekt hoch und Du laesst bspw. die "LIST"-Methode ausfuehren?

Wie händelt Ihr so etwas?

Relationaler Datenzugriff und Objektorientiertheit beissen sich meines Erachtens. Auch mit der Performance siehts oft nicht so toll aus. Also mache schreibe ich _nie_ objektorientierten Datenzugriff.

Aber Deine Herangehensweise ist interessant. (Nur das mit der Sessionspeicherung ist absolut ungewoehnlich.)

Gruss,
Ludger

[Patrik]

Hallo,

Eine SQL-Klasse in der Session zu speichern.. ist das
vollkommener Schwachsinn oder Gang und Gebe?
vermutlich ist das aeusserst ungewoehnlich.
Was ist uebrigens genau eine "SQL-Klasse"?

Also ich habe mir da so eine Art Schablone für Datenbankzugriffe
und -Aktionen gebastelt. Und die (My)SQL-Klasse leitet sich von
einer Solchen ab. Die Schablone ihrerseits liegt hierarchisch
gesehen wiederum einer abstrakten Klasse zugrunde, welche die
eigentlichen 'Mindest-Anforderungen' für eine im System als gültig
anerkannte Datenbank-Klasse bestimmt. Jeder Datenbanktyp hat
dementsprechend eine eigene Implementation dieser abstracten
Datenbankklasse (MySQL,Oracle,Sybase..).
Somit ist u.a. gewährleistet, dass zB erfolgsrelevante Parameter
gesetzt werden (müssen) - wie zB die Zugangsdaten - oder auch
Grund-Methoden implementiert werden (müssen) - wie zB die Iteration
eines Resultsets.
Nun kommt noch hinzu, dass der größte Teil der DB-Daten (Resultsets,
Anzahl Einträge,etc.) gecached wird. Derzeit geschieht das vollkommen
automatisch (dank der DBClass) über die Membervariablen (Arrays) der
DB-Klasse. Somit wird bei jedem Retrieve vorerst geprüft, ob die Daten
evtl. bereits im Cache vorliegen und ggfs. werden die gewünschten
Daten aus dem Cache geladen. Eine Haltbarkeits-Zeit bestimmt wie lange
ein Object im Cache gespeichert werden darf.
So, und angesichts dieser Tatsachen, erscheint es mir sehr abwegig,
diese Klasse nicht sitzungs-persistent zu cachen, da auf diese Art
und Weise gut >paar Dutzend DB-Anfragen entfallen würden.

Du hast einen objektorientierten Datenzugriff entwickelt, also
bspw. kommt ein parametrisiertes Tabellenobjekt hoch und Du laesst
bspw. die "LIST"-Methode ausfuehren?

Die Darstellungsweise spielt auf dieser Schicht noch kein große
Rolle. Das wird später von GUI-Klassen und über Templates geregelt.
Die DB-Klasse sorgt an dieser Stelle zB dafür, dass überhaupt Daten
für eine Liste existieren, ferner auch solch Logiken wie zB das
Auslesen der Daten seitenweise oder aber das Abfangen von Zugriffen,
deren Besitzer keine Rechte für eine derartige Aktion besitzt.

Relationaler Datenzugriff und Objektorientiertheit beissen sich
meines Erachtens. Auch mit der Performance siehts oft nicht so toll
aus. Also mache schreibe ich _nie_ objektorientierten Datenzugriff.

Also ich habe bisher noch keinen Bottleneck spüren müssen. Ich hoffe
auch mal, dass sich da nicht viel ändern wird. M.M.n. ist PHP eine
recht flotte Sprache.

Aber Deine Herangehensweise ist interessant. (Nur das mit der Sessionspeicherung
ist absolut ungewoehnlich.)

Ja, es kam mir selber ja auch komisch vor. Daher auch mein Posting hier ;)
Die größten Bedenken hatte/habe ich eigentlich hinsichtlich der Sicherheit
bzw. dem Auslesen der Session durch Dritte. Sind denn PHP-Sessions allgem.
sicher? Oder kann da jemand mit einiger Mühe theoretisch die Inhalte derer
auslesen?

Gerade ist mir in den Sinn gekommen, die SQL-Klasse evtl. einfach vor jedem
Page-Refresh, oder auch nach relevanten Methodenaufrufen, zu serialisieren
und dann als XML-Datei zu persistieren (gibt's da was Hauseigenes von PHP?).
Und dann nach jedem Refresh die Datei/das Object wieder zu  deserialiseren
und anschließend in den Anwendungsscope zu packen.
Das wäre doch eingentlich eine vernünftige Lösung.

Wie seht Ihr das, spricht etwas gegen die zuletzt genannte Vorgehensweise?

Besten Dank für Antworten.

Grüße aus Berlin
Patrik

[Ludger]

Hi,

Relationaler Datenzugriff und Objektorientiertheit beissen sich
meines Erachtens. Auch mit der Performance siehts oft nicht so toll
aus. Also mache schreibe ich _nie_ objektorientierten Datenzugriff.
Also ich habe bisher noch keinen Bottleneck spüren müssen. Ich hoffe
auch mal, dass sich da nicht viel ändern wird. M.M.n. ist PHP eine
recht flotte Sprache.

ich meinte das anders. Mir gings ums Performance und um die Pflege des Datenzugriffs. Koennen die RDBMSe stored procedures, so pflege ich ein CRUDL-Rudel davon, ansonsten habe ich ein Rudel Funktionen in der Sprache der serverseitigen Logik.
Ausserdem gibt es doch oft fuer jede Datenbanktabelle verschiedene Einstellungen, baust Du fuer diese Datenbanktabellen verschiedene Klassen? (Habe ich vor vielen Jahren auch _einmal_ gemacht. :-)

Aber Deine Herangehensweise ist interessant. (Nur das mit der Sessionspeicherung
ist absolut ungewoehnlich.)
Ja, es kam mir selber ja auch komisch vor. Daher auch mein Posting hier ;)
Die größten Bedenken hatte/habe ich eigentlich hinsichtlich der Sicherheit
bzw. dem Auslesen der Session durch Dritte. Sind denn PHP-Sessions allgem.
sicher? Oder kann da jemand mit einiger Mühe theoretisch die Inhalte derer
auslesen?

Sicherheit ist schon gegeben.   :-)
Was machst Du aber, wenn Du auf nicht mehr aktuellen daten sitzt? Auch mit der referentiellen Integritaet (und anderen Integritaeten und Einstellungen) koennte es hart werden.   :-)

Gerade ist mir in den Sinn gekommen, die SQL-Klasse evtl. einfach vor jedem
Page-Refresh, oder auch nach relevanten Methodenaufrufen, zu serialisieren
und dann als XML-Datei zu persistieren (gibt's da was Hauseigenes von PHP?).
Und dann nach jedem Refresh die Datei/das Object wieder zu  deserialiseren
und anschließend in den Anwendungsscope zu packen.
Das wäre doch eingentlich eine vernünftige Lösung.

Wuerg.   :-)

Wie seht Ihr das, spricht etwas gegen die zuletzt genannte Vorgehensweise?

Deren (unnoetige?) Komplexitaet spricht m.E. dagegen.

Gruss,
Ludger

[Sven Rautenberg]

Moin!

So, und angesichts dieser Tatsachen, erscheint es mir sehr abwegig,
diese Klasse nicht sitzungs-persistent zu cachen, da auf diese Art
und Weise gut >paar Dutzend DB-Anfragen entfallen würden.

"Don't optimize it if you can't measure it."

Du mußt ja immer auch die potentielle Gleichzeitigkeit von Zugriffen innerhalb derselben Session beachten. Ein Cache ist zwar schön und gut, aber indem du die Cache-Logik in PHP realisierst, hast du nicht mehr nur exakt EINEN Cache, sondern dir entsteht mit jedem PHP-Prozess einer. Daran ändern auch Sessions nichts. Zumal Sessions ja auch irgendwie gespeichert werden müssen. Und genau dort sähe ich ein potentielles Problem, denn wenn du so viele Sessions gleichzeitig hast, dass die Datenbank in Schwierigkeiten kommt mit den Abfragen, dann hast du mit Sicherheit auch Probleme mit der HD-Performance bei der Session-Speicherung - denn bekanntlich ist es im Filesystem nicht gut für die Zugriffszeiten, wenn ein Verzeichnis sehr viele Dateien enthält.

Abgesehen davon müssen natürlich die Schreibzugriffe auf die Sessiondaten serialisiert werden. Es ist daher eine gute Idee, die Menge zu schreibender Daten klein zu halten. Das gilt im gleichen Maße auch für eigenentwickelte Mechanismen, die in Dateien speichern.

Im übrigen haben gute Datenbanken alle ihren eigenen Cache schon eingebaut, so dass identische Abfragen sehr schnell bedient werden können. Und genau an diesem Ort macht so ein Cache auch Sinn. Sollte deine Datenbank keine Möglichkeit dazu bieten, würde sich vielmehr anbieten, dass du  dir dann lieber eine cachende DB-API schreibst, die gegenüber der PHP-Applikation wie die Datenbank arbeitet, und seinerseits die Requests zur DB durchreicht. Sowas ist aber definitiv etwas komplizierter und erfordert logischerweise auch die Möglichkeit, es auf dem Server installieren zu können - das ist also nichts für simplen "Webspace".

- Sven Rautenberg

[Tom]

Hello,

das cachen von Daten in einer zu hohen Schicht führt i.d.R eher zu Inkonsistenzen, als zu Vorteilen.

Was mir da sinnvoller zu erscheinen mag, ist einen Shared Memory mit einem "Server" einzurichten, über den alle Zugriffe abgewickelt werden. PHP stellt dafür Schnittstellen zur Verfügung. Habe ich aber noch nie ausprobiert, obwohl ich es immer schon mal wollte.

http://de3.php.net/sem

Der gemeinsame Speicherbereich steht allen zur Zeit aktiven Scripten, die von ihm wissen und ihn ansprechen dürfen jederzeit (unter Berücksichtigung der einzubauenden Zugriffskontrollen) gleichzeitig zur Verfügung. Sessiondateien hingegen stehen immer nur genau einem Script gleichzeitig zur Verfügung. Die Zugriffe darauf sind also "script-serialisiert" und nicht "zugriffs-serialisiert". Also erst, wenn das erste Script beendet wird und/oder die Sessiondatei wieder freigibt, kann das nächste darauf zugreifen und sperrt sie dadurch seinerseits wieder. Man müsste bei einer Sessiondatei also diese bewusst wieder freigeben, wenn man (als Script) sie gerade nicht selber benötigt, und sie dann wieder sperren (durch Neustart der Session) wenn man sie doch nochmal benötigt. Das würde natürlich zum Neueinlesen der dann hoffentlich gerade freien Datei führen.

Harzliche Grüße vom Berg
esst mehr http://www.harte-harzer.de

Tom

[wahsaga]

hi,

Die größten Bedenken hatte/habe ich eigentlich hinsichtlich der Sicherheit bzw. dem Auslesen der Session durch Dritte. Sind denn PHP-Sessions allgem. sicher? Oder kann da jemand mit einiger Mühe theoretisch die Inhalte derer auslesen?

Der gröbste Fehler, den Provider gerne bei der Konfiguration machen, ist der, die Session-Dateien einfach in einem temp-Verzeichnis abzulegen, auf das alle User einer shared Hosting-Umgebung Zugriff haben.
Du solltest also auf jeden Fall darauf achten, dass deine Session-Dateien in einem temporären Verzeichnis unterhalb deines User-Accounts landen, auf den andere Nutzer dank safe_mode und/oder open_basedir nicht so einfach zugriff haben (dass die Konfiguration in diesem Punkte vernünftig sein muss, ist natürlich offensichtliche Voraussetzung).
Verantwortliche Konfigurationseinstellung ist session.save_path.

gruß,
wahsaga

[Sven Rautenberg]

Moin!

Eine SQL-Klasse in der Session zu speichern.. ist das
vollkommener Schwachsinn oder Gang und Gebe?

Schwachsinn. :)

Oder gibt es Alternativen hinsichtlich Globalisierung der
SQL-Klasse, so dass ich sie nicht in jeder anderen Klasse
erneut instanziieren, oder sie ständig übergeben muss?

Bei der PHP-Programmierung ist die Tatsache, dass die Skripte ständig gestartet und wieder beendet werden, ohne dass einmal angelegte Variablen und Objekte erhalten bleiben, in der Tat ein etwas störender Vorgang, der einige systematische Ansätze wie eben OOP auf den ersten Blick recht sinnlos erscheinen läßt.

Aber der Sinn von OOP liegt viel eher in seiner ordnenden Strukturierung des Programmcodes, weniger in der Tatsache, dass man Objekte nur einmal anlegt und dann ewig weiterbenutzt.

Denn selbst wenn du ein Objekt in eine Session speicherst, würden dort ausschließlich die aktuellen Objektvariablen landen, aber keine weiteren Zustände. Ein Skript, welches diese Variablen wieder nutzbar machen will, muß zuerst die Klassendefinition einlesen (die also so oder so geparst werden muß), erst danach darf die Session gestartet werden. Und hergestellte Datenbankverbindungen müssen trotzdem neu aufgemacht werden (PHP bietet dafür allerdings die Möglichkeit, in der Klasse Methoden zu definieren, die beim Verlassen und Neueinlesen einer Instanz z.B. in einer Session ausgeführt werden).

Ob es tatsächlich sinnvoll ist, eine DB-Klasse in die Session zu packen, hüngt vermutlich von dem Gesamtbild ab, das sich bei deiner Aufgabenstellung und dem gewählten Lösungsansatz bietet. Es wäre aber in der Tat sehr ungewöhnlich.

- Sven Rautenberg