Statische Daten per Adminpanel verändern

[Rafael]

Hallo,
ich habe folgende Problemstellung (an mich selbst). Ich möchte quasi statische Daten durch eine Eingabemaske festlegen lassen. Also durch einen Laien ein Dokument mit einem längeren Array darin erzeugen lassen.
Bisher habe ich das Array einfach mit einem Editor erstellt. Die darin enthaltenen Daten sind im Grunde fest und werden in der Regel nur beim Einrichten des Programmes gesetzt.

Natürlich könnte ich diese Informationen nun in einer Datenbanktabelle speichern. Da meine Anwendung aber ohnehin schon zahlreiche Datenbankzugriffe verzeichnet wollte ich das eigentlich vermeiden, da ich die Informationen bei eigentlich jedem Seitenaufruf benötige.
Ist es für solche Fälle usus mittels PHP ein PHP-Dokument zu erzeugen, dass dieses Array enthält und dieses in mein Programm einzubinden? Oder sollte man von solchen Lösungen lieber die Finger lassen, da ja unter Umständen ein der Parser auf einen Fehler stoßen könnte, wenn man eine Eventualität übersieht oder einfach der Speichervorgang unterbricht.

Oder ist es ratsam, die Informationen in einer Session-Variable zwischen zu speichern? Wie viel Information verträgt so eine Zwischenspeicherung denn? Es wären an die 1000 bis 10000 Werte, bei 10 bis 100 Nutzern gleichzeitig, je nach Umfang der Nutzung. Ich fürchte, dass das den Arbeitsspeicher ein wenig überlassten könnte. (Die Session-Variablen wären aber für alle Nutzer identisch, was sich wohl nicht ausnutzen lässt.)

Danke für Ratschläge!

[Sven Rautenberg]

Moin!

Natürlich könnte ich diese Informationen nun in einer Datenbanktabelle speichern. Da meine Anwendung aber ohnehin schon zahlreiche Datenbankzugriffe verzeichnet wollte ich das eigentlich vermeiden, da ich die Informationen bei eigentlich jedem Seitenaufruf benötige.

ALLE Informationen? Oder nur gezielt einzelne Informationen? Und stehen diese Werte mit der Datenbank in irgendeiner Beziehung?

Ist es für solche Fälle usus mittels PHP ein PHP-Dokument zu erzeugen, dass dieses Array enthält und dieses in mein Programm einzubinden? Oder sollte man von solchen Lösungen lieber die Finger lassen, da ja unter Umständen ein der Parser auf einen Fehler stoßen könnte, wenn man eine Eventualität übersieht oder einfach der Speichervorgang unterbricht.

Wenn man es richtig macht, kann nichts passieren. Stichwort serialize()/unserialize(). Diese Funktionen sorgen für eine syntaxgerechte Behandlung aller Zeichen, die man in einem Array so speichern kann. Zusammen mit ein wenig Escaping kannst du dir recht simpel eine PHP-Zeile erstellen, die dir die Array-Werte wieder zur Verfügung stellt.

Oder ist es ratsam, die Informationen in einer Session-Variable zwischen zu speichern?

Wie kommen die Daten in die Session? Und wie stellst du sicher, dass die Daten in allen Sessions gleichzeitig aktualisiert werden, wenn sich der unwahrscheinliche Fall ergibt, dass du in den Daten doch mal was ändern mußt?

Nein, Sessiondaten sollten wirklich nur für Sessionwerte genutzt werden. Das ist auch programmlogisch übersichtlicher.

Wie viel Information verträgt so eine Zwischenspeicherung denn? Es wären an die 1000 bis 10000 Werte, bei 10 bis 100 Nutzern gleichzeitig, je nach Umfang der Nutzung. Ich fürchte, dass das den Arbeitsspeicher ein wenig überlassten könnte. (Die Session-Variablen wären aber für alle Nutzer identisch, was sich wohl nicht ausnutzen lässt.)

Du kannst in PHP allgemein nur begrenzt Variablen speichern, das Maximum wird durch memory_limit bestimmt. Session-Variablen werden, wenn keine selbstprogrammierte Speichermethode genutzt wird, aus einer Textdatei ausgelesen, in der sie serialisiert gespeichert sind. Viele Daten = große Textdatei = mehr Zeitaufwand beim deserialisieren. Entsprechend wird am Skriptende wieder diese Textdatei beschrieben. Viele Daten = mehr Aufwand beim serialisieren = große Textdatei. Da unveränderliche Werte aber nun absolut nicht jedes Mal erneut gespeichert werden müssen, ist die Session absolut der falsche Ort dafür.

Eine PHP-Datei mit wahlweise Serialisierung oder direkter Erzeugung eines Arrays zu parsen kostet zwar auch Aufwand und Zeit - aber die Datei wird nur einmal pro Skript gelesen. Dasselbe stimmt, wenn man die Daten stattdessen in der Datenbank speichert. Das dürfte einen Tick zeitaufwendiger sein, aber wenn die Fixdaten mit den anderen DB-Daten in Beziehung stehen, ergibt sich u.U. ein konsistenteres Datenmodell. Deshalb hängt es tatsächlich von der Art der Daten ab, wo diese am schlauesten untergebracht werden.

Unter Performancegesichtspunkten an die Sache heranzugehen halte ich solange für unsinnig, solange kein anderer Teil des Codes auch unter diesem Gesichtspunkt durchleuchtet worden ist - und solange die Performance keine Probleme macht.

- Sven Rautenberg

[Rafael]

Hallo,
ersteinmal danke für deinen ausführlichen Ratschlag.
Der Plan ist der folgende: Ich möchte eine Art PhpMyAdmin kreieren. Nur für einen völlig anderen Anwendungsbereich.

Ich möchte es auch einem Laien ermöglichen Datenbanken zu verwalten und dafür gebe ich nun einen vergleichsweise strengen Rahmen für die Nutzung der Datenbanken-Formulare wie man sie aus PHPMyAdmin kennt. Eine Möglichkeit eigene SQL-Kommandos zu senden gibt es bei mir beispielsweise nicht. Dafür lässt sich sehr einfach ein neuer Datenbankeintrag in eine, bisher MySQL oder Postgres-Datenbank einfügen, die vorhanden Einträge lassen sich nach Alphabet in Listen sortieren, in Vollansicht darstellen, als PDF ausgeben etc...
Mit technischen Finessen wird man dabei nicht konfrontiert.

Ich bin mit dem Nutzerbackend auch schon ziemlich weit, im Grunde ist dieser Teil sogar einsatzbereit und es lässt sich jede Datenbank ohne größere Umschweife an die Verwaltung anschließen. (Für jemanden der weiß wie in 2 Minuten erledigt)

Eben auf Grund dieses "Weiß-wie" möchte ich nun einem "Admin-Nutzer" die Möglichkeit geben Felder umzubenennen, ohne dass die eigentliche Datenbank betroffen ist bzw. soll er auch Eingabeoptionen setzen dürfen, die die Datenbank an sich auch unverändert lässt. Bisher wird beispielsweise ein MySQL-Enum-Feld automatisch als Optionsfeld ausgegeben. Nun soll aber auch ein normales Textfeld als Optionsfeld geführt werden können, sofern dies vom "Admin-Nutzer" gewünscht wird.

All dies ist momentan in einem relativ großen Array gespeichert. So wird zum Beispiel per

$sys_var['Optionsfelder']['Datenbank']['Feldname'] = 'Wahl1##Wahl2##Wahl3';

beim anzeigen der Datenbank 'Datenbank' wird ein Feld 'Feldname' dann automatisch als Optionsfeld mit den Alternativen Wahl 1 bis 3 geführt. Derartige Funktionen gibt es aber einige womit sich die Masse der Informationen ziemlich ausbreitet. Nun könnte ich eben diese Informationen zwar auch in selbiger Datenbank ablegen, gerade diese wollte ich, wegen des neutralenen Verwaltungscharakters aber gerne unberührt lassen.

Wenn ich diese Informationen nun in der Verwaltungseigenen Datenbank ablege, die ich ohnehin für Nutzerpasswörter etc. benötige, müsste ich bei jedem Aufruf einer Seite erst die "eigene", dann die auszulesende Datenbank anrufen. Daher die Idee die Datei, die bisher als Behelfslösung herhalten musste, in anderer Form weiterzuführen, da ich annehme, dass Feldinformationen relativ einmalig gesetzt werden.

Ist serialize dann angebracht? Danke schon einmal und viele Grüße!

PS: Sorry, dass ich die Katze nicht gleich aus dem Sack gelassen habe, ich dachte durch das Abstrahieren meines Problems mache ich die Sache angenehmer zu beantworten, da ich durchaus nur nach einer hoffentlich brauchbaren Richtung fragen will, um micht nicht irgendwann ärgern zu müssen falsch angesetzt zu haben.

[King^Lully]

All dies ist momentan in einem relativ großen Array gespeichert.

Interessantes Vorhaben, Du hast also eine relativ grosse Struktur, die Du nicht sofort in die DB umsetzen möchtest, sondern erst, wenn der Nutzer die Modellierung beendet hat. Und Du fragst Dich wie Du diese Struktur speichern sollst. Tja, in einer Session(Datei), einer Datei oder in einer DB, hast Du was gegen DBs?

[Rafael]

hast Du was gegen DBs?

Wie gesagt nur in der Beziehung, dass ich diese möglichst unberührt lassen möchte. Ich werde dass mit den Dateien mal ausprobieren und dann wird sich schon herausstellen, ob es für mich funktioniert.
Des weitern soll die Struktur nicht in die Datenbank umgesetzt werden. Sie soll nur und ausschließlich für meine Verwaltung gelten. Daher schrecke ich irgendwie vor der Datenbankenlösung zurück, da diese einen Eingriff in das "äußere Feld" mit sich bringt.
Außer eben ich schreibe die Informationen in die Hauseigene Datenbank, was aber eine Querverbindung bei jedem Zugriff mit sich bringen würde...

[King^Lully]

Des weitern soll die Struktur nicht in die Datenbank umgesetzt werden. Sie soll nur und ausschließlich für meine Verwaltung gelten. Daher schrecke ich irgendwie vor der Datenbankenlösung zurück, da diese einen Eingriff in das "äußere Feld" mit sich bringt.

Wer sagt, dass mit dem "nicht sollen"? "Äuseres Feld" übersteigt mein Abstraktionsvermögen.

Aber noch mal eine ganz klare Antwort:
Man hat immer Daten, die eine Sitzung betreffen - sofern ein Sitzungssystem/Berechtigungssystem gegeben ist.   ;)
Und diese Daten kann man eben in der Sitzungsdatei, in einer anderen Datei oder in einer DB speichern, Deine Anforderungslage ist trivial, auch wenn eine grössere komplexe Datenstruktur gegeben ist.
Ich würde die Daten in einer DB speichern und mir über "Performance&Co" keine Gedanken machen, für die Datenspeicherung sind "Datenspeicherungsanlagen" schliesslich da.
Also, sitzungsspezifische, "unwichtige" Daten in die Session, sonst alles in die DB. Ich finde die Sitzungsverwaltung per DB zudem besser als dieses Dateiengefrickel.

[Rafael]

Hmm, ich denke gerade an eine XML-Datei und ein zugehöriges XML-Objekt. Theoretisch sollte das doch auch funktionieren...