[PHP/MySQL] Performance bei Konfiguration in DB

[Astrodan]

nabend!

ich habe bei meinem Skript ein paar Konfigurationseinträge in einer Datenbank-Tabelle gespeichert.

Schema der Tabelle ist wie folgt

id | option_name | option_value
1 | default_page | news
2 | disabled | false
...

Nun stellt sich mir allerdings die Frage, wie es sich von der Performance her am ehesten lohnt die Daten auszulesen.
Derzeit habe ich eine Funktion, die mir das auslesen der Konfiguration ermöglicht, indem man ihr die entsprechende Option als Parameter übergibt, und diese dann die DB abfragt.
Sollte eine aufgerufene Seite mehrere Konfigurationseinträge benötigen, so würde dies nach dem aktuellen Schema pro benötigter Info einen Query bedeuten, was vermutlich auf Dauer stark auf die Performance geht.

Nun überlege ich, zwei verschiedene Möglichkeiten einzuführen:

a) Beim Laden des Skripts (include) wird eine Klasse geladen, die die Optionen auslesen kann. Einmal ausgelesene Optionen werden zwischengespeichert.
=> Vorteil: Minimale Speicherauslastung
=> Nachteil: kaum weniger Querys

b) Beim Laden des Skripts wird eine Klasse geladen, welche direkt die ganze Tabelle mit den Optionen ausliest und speichert.
=> Vorteil: Schnell, wenige Querys
=> Nachteil: je nach Anzahl der Optionen großer Speicherbedarf

Natürlich gäbe es auch noch die Möglichkeit beispielsweise eine weitere Spalte hinzuzufügen, in der eingetragen ist, ob die Option immer ausgelesen werden soll, so dass die Methode b) etwas weniger speicherintensiv ist, aber dafür für außergewöhnliche Optionen extra Anfragen braucht.

Leider weiß ich nicht genau, in wie weit das ganze jetzt den Seitenaufbau bremst/beschleunigt. Deswegen wollt ich mal fragen, welche Methode am empfehlenswertesten ist.
Oder hab ich noch eine gute Möglichkeit übersehen?

 

[MrToiz]

Also ich denke doch, so lange du nicht gleich ein paar Hundert Optionen hast, wird Variante b am performantesten sein.

 

[leller]

Hallo,

ich würde eigentlich immer zur Methode tendieren, die alle Informationen auf einen Schlag ausliest, da die Zeit für zusätzliche DB-Abfrage IMHO immer den Nachteil des zusätzlichen Speicherplatzbedarf aufwiegen. Es sei denn du hast mehrere tausend Configeinstellungen, die mehrere MB umfassen.

 

[whirpool]

Ich schliesse mich MrToiz und leller an.

Bei einer Seite von mir die nur wenige optionen hat habe ich es noch etwas anders gemacht.
Ist zwar ein echter db-frevel und ich hoffe nicht gesteinigt zu werden, aber es ist wohl die unkomplizierteste weise die optionen abzufragen.

Ich habe einfach eine Tabelle mit nur einem Datensatz angelegt.
die Spalten sind nach den Optionen benannt und in dem einen Datensatz dann die entsprechenden Werte.

Also z.B.

Seite | DefaultPage | AllowLogin | SiteStatus | ...
--------------------------------------------------
__1__|__News_____|___1_____|___1______| ...

Im Query wird der datensatz "Seite = 1" abgerufen.
Die entsprechenden Werte wie z.B. bei 'AllowLogin' werden dann über einen array zugeodnet. array(0 => "Anonym", 1 => "User", 2 => "Admin", 3 => SiteAdmin)..
Einigen weden sich die fussnägel hochrollen wenn sie das lesen, aber ist eine recht einfach art ;o)

Gruß,
Whirpool

 

[Astrodan]

Erstmal danke an alle Antworten bisher.
Ich denke, ich werde dann einfach mal Variante b) ausprobieren.

Ich habe einfach eine Tabelle mit nur einem Datensatz angelegt.
die Spalten sind nach den Optionen benannt und in dem einen Datensatz dann die entsprechenden Werte.

Also, dafür würd ich dich jetzt am liebsten steinigen. Wenn du es eh in einen Array schreibst, warum speicherst du es dann nicht in einer Tabelle ähnlich wie meiner direkt als Array, gespeichert per serialize();

 

[whirpool]

Also, dafür würd ich dich jetzt am liebsten steinigen. Wenn du es eh in einen Array schreibst, warum speicherst du es dann nicht in einer Tabelle ähnlich wie meiner direkt als Array, gespeichert per serialize();

hab ja gesagt das es ein frevel ist und hoffe nicht gesteinigt zu werden
wollte nur eine weitere möglichkeit aufzeigen nach der du gefragt hast
Die art in der du es jetzt machst ist natürlich die sauberere weise und so sollte es auch sein.

 

[Astrodan]

hab ja gesagt das es ein frevel ist und hoffe nicht gesteinigt zu werden

hättest du das wort steinigen nicht benutzt hätte ich das auch nicht getan

Allerdings würde mich schon mal interessieren, ob die Variante mit serialize() für dich nicht sogar schneller und effektiver wäre (da direkt im Array alles sortiert ist).

 

[MrToiz]

Naja so viel sauberer find ich die Variante gar nicht, denn mir gefällt es absolut nicht, wenn ich Integer-Werte in ein Textfeld speichern muss, aber dafür ist mir bisher noch keine Patent-Lösung eingefallen. Klar kann man ein zusätzliches Feld anlegen, in dem man den Typ speichert, und dann nach dem Auslesen entsprechend anpassen, aber von sauber ist das ja noch weit entfernt.

 

[whirpool]

hättest du das wort steinigen nicht benutzt hätte ich das auch nicht getan

*g* hat den vorteil gehabt das meine freundin grade mal länger nach steinen suchen musste als sie mit werfen an der reihe war

Allerdings würde mich schon mal interessieren, ob die Variante mit serialize() für dich nicht sogar schneller und effektiver wäre (da direkt im Array alles sortiert ist).

hmm.. schneller und effektiver.. *kratz*.. bei vielen optionen evtl. schon aber bei ca 10 Optionen die dort sind ist der code einfacher nachzuvollziehen wenn man weniger umwege geht.
Z.B. das AllowLogin..
Ich habe User-Level von 0-4 festgelegt. 0=Anonym, 1=User, 2=admin, 3=SiteAdmin und 4=Super-Admin. Das UserLevel findet sich in dem Datensatz des Users wieder.
Im Code schaut das beim Login dann inetwa so aus:

if($userData['UserLevel'] >= $siteCtl['AllowLogin]) {
// User wird eingeloggt => weiter im text
} else {
// Keine erechtigung => Fehlerhinweis wird ausgegeben
}

lässt sich halt im code und der DB selbst sehr einfach lesen und nachvollziehen wie ich meine )
und einfache lesbarkeit und nicht zu verschachtelte vorgänge sind beim debuggen ja des programmierers freund *g* (Siehe sig )
zudem ist ausser einem query und fetch_assoc nix nötig um die globale Konfiguration zu laden.

Naja so viel sauberer find ich die Variante gar nicht, denn mir gefällt es absolut nicht, wenn ich Integer-Werte in ein Textfeld speichern muss, aber dafür ist mir bisher noch keine Patent-Lösung eingefallen.

Das stimmt auch. Das ist ein vorteil wenn ma es alles in einen datensatz knallt. tinyint(1) unsigned und gut ist..
Doch bei einer seite die man "überkonfigurieren" kann artet das wohl etwas aus. da ist es schon nett wenn man auch nur teile der config laden kann .

mit serialize() habe ich mal gearbeitet als ich mir eine seite zum zugriff auf daten eines pc's im lan über ein webinterface mithilfe von perl&samba gebastelt habe und habe eigendlich nurnoch den krampf in erinnerung den ich damit hatte *g*
seitdem habe ich es glaube ich nicht wieder eingesetzt *g*
[€dit]Damit will ich sagen das ich nicht wirklich weiss mit serialize() umzugehen [/€dit]


ich sach schonmal eine gute nacht.
mein kopp tut weh.. ich sage nur:
"Parse error: syntax error, unexpected $end in .... on line 2274"
in zeile 1539 fehlte ne "}" nach der ich die letzten 40min gesucht habe ^^

Gruß,
Whirpool

 

[MrToiz]

mein kopp tut weh.. ich sage nur:
"Parse error: syntax error, unexpected $end in .... on line 2274"
in zeile 1539 fehlte ne "}" nach der ich die letzten 40min gesucht habe ^^

->Programmieren ist die höchste Kunst der Selbstverarschung<-

BTW: 1. Rückst du deinen Code nicht ein? Bei mir fällt es dadurch meistens auf, wenn irgendwo ne Klammer fehlt.
2. Was willst du auch mit 2274 Zeilen in einem Script, da lässt sich bestimmt was auslagern und nachher wieder includen (OMG, da erinner ich mich gerade an ein Script, das ich mal irgendwo gefunden habe, da waren in jeder Datei nur 50 Zeilen und in der Hauptdatei stand dann ungefähr include("Zeile1-50.php");include("Zeile51-100.php"); )

 

[Sebbo]

Hallo

Ich weiß nicht ganz genau, welche Anforderungen an deine Konfigurations-Einträge gestellt werden. (z.B. ob sie per Web-Oberfläche zu editieren sind).

Wenn sie nicht (oder nicht sehr oft) zu editieren sind, dann kannst du sie ja auch in eine PHP-Datei auslagern und die Includen. Da spart man sich die gesamte Datenbankabfragerei. Vielleicht kann man die Einstellungen auch irgendwie Gruppieren und in mehrere Dateien auslagern, so dass möglichst immer nur die benötigten Einstellungen includet werden.

Aber das kommt halt auf die Seite an. Evtl. geht das garnicht.

 

[whirpool]

BTW: 1. Rückst du deinen Code nicht ein? Bei mir fällt es dadurch meistens auf, wenn irgendwo ne Klammer fehlt.

ja, ich achte sogarn peinlich drauf das bei mir alles korrekt eingerückt ist )
so kommen auch die 2274 zeilen bei gut 28KB code zustande ^^
sind eine menge arrays drinne die ich brauche und die sehen dann halt mal so aus:
$blub = array("a" => "b",
____________"b" => "c" ...
und leider brauche ich da ein paar mehr von *g*
wusste ja auch wo in etwa ich da blind am pfuschen war, aber der teufel liegt halt im detail

2. Was willst du auch mit 2274 Zeilen in einem Script, da lässt sich bestimmt was auslagern und nachher wieder includen

die eine oder andere funktion lässt sich evtl noch auslagern da sie (noch) mit funktionen identisch ist die ich anderswo nutze, aber das mache ich erst wenn das script läuft und ich mir sicher bin das ich den schmarn nicht wieder umschreiben muss
der grossteil ist halt zuweisung von vars. die eigendliche scriptlogik wird so bei ~1300 gut eingerückten und formatierten zeilen liegen denke ich.
und kommentieren tu ich auch gerne mal nen wenig mehr, da noch wer anders durch den code durchsteigen muss ;o)
hört sich alles schlimmer an als es ist, aber es läppert sich halt und wenn man dann nichtmehr so ganz fit ist sieht man den wald vor lauter baeumen nichtmehr *g*

(OMG, da erinner ich mich gerade an ein Script, das ich mal irgendwo gefunden habe, da waren in jeder Datei nur 50 Zeilen und in der Hauptdatei stand dann ungefähr include("Zeile1-50.php");include("Zeile51-100.php"); )

na, das ist aber mal nen wenig übertrieben *gg* erinnert mich ja nen wenig an die codeconventions die ich früher bei basic einhalten musste. man, gab das vom lehrer wenn da nur ein zeichen mehr als 80 in einer zeile war

 

[Benutzer-621]

Moin,
machst halt ein Script, dass dir aus den Konfigurationen eine neue Datei erstellt, wenn dann eine Option geändert wird erstellst sie erneut.

 

[Astrodan]

hmm.. schneller und effektiver.. *kratz*.. bei vielen optionen evtl. schon aber bei ca 10 Optionen die dort sind ist der code einfacher nachzuvollziehen wenn man weniger umwege geht.

Okey, das mag sein.

Z.B. das AllowLogin..
Ich habe User-Level von 0-4 festgelegt. 0=Anonym, 1=User, 2=admin, 3=SiteAdmin und 4=Super-Admin. Das UserLevel findet sich in dem Datensatz des Users wieder.

Das wiederum find ich weniger gut
Wenn du es schon auf die Art und weise machst, könntest du das entsprechende Feld dann wenigens vom Typ enum machen, und dann halt als Werte 'anonym','user','admin',... angeben. Erhäht die Lesbarkeit im Code enorm, und der Speicherplatzmehrverbrauch in der Datenbank ist wohl nicht wirklich relevant.

lässt sich halt im code und der DB selbst sehr einfach lesen und nachvollziehen wie ich meine )

Geht noch besser (s.o.)

 

[whirpool]

Das wiederum find ich weniger gut
Wenn du es schon auf die Art und weise machst, könntest du das entsprechende Feld dann wenigens vom Typ enum machen, und dann halt als Werte 'anonym','user','admin',... angeben. Erhäht die Lesbarkeit im Code enorm, und der Speicherplatzmehrverbrauch in der Datenbank ist wohl nicht wirklich relevant.

erwischt den fisch
hast recht, wrde mal sehen ob ich das noch abändere.. an enum hatte ich nicht gedacht. dank für den hinweis

 

[Astrodan]

erwischt den fisch
hast recht, wrde mal sehen ob ich das noch abändere.. an enum hatte ich nicht gedacht. dank für den hinweis

Kein Problem.
Ich sollt häufiger Threads mit Fragen aufmachen, in denen ich anderen Leuten helfe.

Und da ichs bisher vergessen habe:

@Sebbo:

Klar, das Prinzip mit den config-Dateien ist das einfachste, darüber läuft auch sowas wie Datenbank-Passwort und grundlegende Einstellungen, die eigentlich nicht verändert werden sollen.
Aber die eigentlichen Optionen sind im Admin-Bereich umstellbar, was auch sinnvoll ist, da ich zwar Codetechnisch der Meister der Seite bin, aber die Inhalte und deren Anzeige von anderen definiert werden. Und ich denke es ist verständlich, dass ich keine Lust habe mich um jeden sch* zu kümmern.
Und von der Möglichkeit, eine PHP-Config-Datei mit PHP zu schreiben möchte ich mal absehen, das wird mir zu komplex und erfordert nebenbei bei der Skript-Installation das Setzen von Benutzerrechten, was sicherlich einige vergessen könnten

Trotzdem natürlich danke für den Vorschlag!

 

[Sebbo]

Deswegen hab ich ja in meinem Beitrag auch geschrieben, dass ich nicht genau weiß, welche Anforderungen gestellt werden. So wie du es jetzt beschreibst, ist eine Datenbank schon richtig. (Aber vielleicht hilft das mit den Dateien ja jemand anderem...)

Und den Vorschlag von tester, die Sachen per Script in die Datei zu schreiben ist zwar nicht super-komplex. Aber aus Sicherheitsgründen sollte man das nicht machen. Nicht umsonst meckern die meisten großen Scripte rum, wenn die Config-Datei lesbar ist.

 

[whirpool]

Und den Vorschlag von tester, die Sachen per Script in die Datei zu schreiben ist zwar nicht super-komplex. Aber aus Sicherheitsgründen sollte man das nicht machen. Nicht umsonst meckern die meisten großen Scripte rum, wenn die Config-Datei lesbar ist.

erm.. also wer die config als plaintext speichert ist ja nun wirklich selber schuld.
unter einer config verstehe ich eine in php gehaltene datei a'la:

<?php
if($meineGeheimeIncludeSicherung === TRUE) {[INDENT]$meineGeheimeIncludeSicherung = FALSE;
$conf['var1'] = "blub";
...
[/INDENT]}
?>

das sollte ausreichen um die daten vor einem direkten aufruf zu sichern.
man kann natürlch auch einen string-wert("mklar89z435tfn") anstatt einem bool als sicherung nehmen.
Die sicherung per variable ist zu empfehlen fals der angreifer zufällig auf dem selben server liegt oder von der eigenen seite kommt.

Gruß,
Whirpool

 

[coaching]

Wenn es sich nicht gerade um tausende von Einträgen handelt und die zugeweisenen Werte doch ohnehin meißt gleich bleiben, würde ich eher zu nem txt-file tendieren.
Wozu die unnötigen Anfragen an die DB?
Eine Konfigurationsdatei schreiben, includen und in einem Adminsitrationsbereich zu verwalten ist nicht schwerer als ne Datenbank anzulegen ;-)

 

[Astrodan]

Eine Konfigurationsdatei schreiben, includen und in einem Adminsitrationsbereich zu verwalten ist nicht schwerer als ne Datenbank anzulegen ;-)

Die Verwaltung derselben würde immer bedeuten, dass man sie am einfachsten komplett neu schreibt. Und das anlegen einer Tabelle in der Datenbank ist nun wirklich keine Arbeit. Datenbank muss ja eh da sein, oder speicherst du beispielsweise deine Newsbeiträge in ner txt-Datei?

Und nochwas, txt-Datei ist ja wohl mit die tollste Sache die du machen kannst, die parst PHP im Normalfall nämlich nicht, d.h. wer jemals den Pfad zu der findet kann sich sämtliche Einstellungen direkt angucken.