Neue DB-Abfrage oder zwischenspeichern?

[DanMan]

Ich stell mir gerade die Frage, ob es besser ist Daten immer wieder aus der DB abzurufen, wenn man sie an verschiedenen Stellen wieder braucht, oder ob man die Daten dann lieber z.B. in einem Array vorhalten sollte.

Wie seht ihr das? Konkret gehts mir um PHP und MySQL. Was ist da schneller bzw. effizienter?

[Demirug]

Schneller ist es natürlich es selbst zwischenzuspeichern. Allerdings sollte man sich bevor man so etwas implementiert immer fragen ob dort wirklich der Flaschenhals ist.

[Monger]

Das kann man so pauschal nicht sagen. Immer dran denken:
"The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!): Don't do it yet.” (Link (http://en.wikipedia.org/wiki/Premature_optimization#Quotes))

Wenn du Werte im Speicher hältst, hast du natürlich unheimlich schnellen Zugriff darauf. Auf der anderen Seite: Wird der Speicher zu voll, wird früher oder später das Geswappe losgehen. Da wird die Datenbank schneller sein, weil die intern die Zugriffe vernünftig cached.

Man kann für beide Situationen Szenarien entwerfen, wo dieses oder jenes schneller ist. In der Praxis wirst du aber erstmal eine Menge Daten haben müssen, damit so eine Frage wirklich relevant wird.

Deshalb: nimm die einfachere Lösung, d.h. das was sich schöner und schneller programmieren lässt, und pfeif auf die Performance. Ohne repräsentative Performance Messungen an realen Szenarien kannst du sowieso nicht entscheiden, was schneller ist.

[DanMan]

Es geht um einen (in diesem Fall kleinen - <50 Artikel) Onlineshop. Da frage ich mich eben, ob es besser ist einmal alle Artikel mit den relevanten Zusatzinfos (Größen, Farben, ...) abzurufen und in ein Array oder Objekt zu stecken, und dann damit weiter zu arbeiten.

Hier dürfte es wohl in der Tat keine Rolle spielen. Aber wenn es mal ein paar Tausend Artikel sind, dann hab ich bedenken, dass es wegen dem mords PHP Speicherbedarf besser wäre die DB öfter zu belästigen. Ich hab da eben (noch) keine Erfahrungswerte, und möcht nicht blind gegen die Wand laufen.

Habs bisher so gehalten, dass wenn ich Daten auf einer Seite nur 1x brauche sie direkt ausspucke, und nur wenn ich sie an mehreren Stellen brauche sie in ein Array ausgebe. Euren Beiträgen zu folge lieg ich damit wohl schon ganz richtig, oder?

[Monger]

Habs bisher so gehalten, dass wenn ich Daten auf einer Seite nur 1x brauche sie direkt ausspucke, und nur wenn ich sie an mehreren Stellen brauche sie in ein Array ausgebe. Euren Beiträgen zu folge lieg ich damit wohl schon ganz richtig, oder?

Ich kann dir dazu jetzt nichts sagen, ohne direkt den Quellcode zu sehen. Aber vergiss nicht, dass eine Datenbank auch nicht gerade doof ist. Wenn das eine gute Datenbank ist, analysiert die wie häufig Anfragen auf bestimmte Daten kommen, und hält die im Cache. Damit bist du dann genauso schnell, wenn nicht sogar schneller als wenn es im Programmspeicher liegt (vergiss nicht, dass auch dein Programm irgendeine Form der Ressourcenverwaltung benötigt, die du halt meistens nicht siehst. Bei Java und .NET muss die Runtime auch einen Objekt-Heap verarbeiten. Bei vielen Objekten bricht die Performance möglicherweise auch dort ein).

Mal noch ein Beispiel: in der .NET Welt gibt es seit einiger Zeit Mini-SQL Datenbanken, die sich direkt in die Anwendung integrieren. Früher galt da noch, dass der Overhead bremst, und man deshalb bei kleineren Datenmengen man doch lieber zu anderen Maßnahmen greifen soll.
Das scheint sich mittlerweile grundlegend geändert zu haben. Bin ehrlich gesagt kein Datenbank-Guru, aber jede hundsgewöhnliche, aktuelle Datenbank sollte da locker deinen Ansprüchen genügen. Bevor du da einen Flaschenhals bei der CPU bekommst, kriegst du lange, LANGE vorher ein Bandbreitenproblem.

Deshalb: wenn es für dich die Sache einfacher macht, greif immer direkt auf die Datenbank zu.

[DanMan]

Deshalb: wenn es für dich die Sache einfacher macht, greif immer direkt auf die Datenbank zu.
Hmm, also doch besser neu abfragen; ok. Dass die DB auch Abfragen zwischenspeichert war mir so nicht bewusst - bin auch kein DB-Guru. Gut zu wissen.

Einfacher fänd ich zwar sich 1x ein Array zusammenbauen und dann nur noch drauf zuzugreifen, aber wenn das bedenklich ist, dann mach ichs eben anders.

Danke für die Tips auf jeden Fall. :)

[dav133]

Das mit dem datenbankseitigem Caching von Abfragen bezieht sich allerdings nur (zumindest ist das mein Wissensstand in mysql) auf gleiche Abfragen, weswegen oft empfohlen wird, eine Abfrage zu erstellen, die zwar auch Daten aus der DB lädt, die für die aktuelle Seite nicht von Nöten sind, allerdings auf den weiteren Unterseiten benötigt werden.

Beispielsweise würde man also bezogen auf deinen Onlineshop das ganze in verschiedene, größere Abfragen aufteilen und so alle Produkte aus der Kategorie Hardware in einem Rutsch abfragen (Ram, HDD, Monitore...) wenn der Umfang nicht grad überdimensional ist, um dann diese Kategorie erschlagen zu haben und auf den weiteren Unterseiten vom caching profitieren zu können. Wenn du jetzt allerdings auf Seite 1 alle HDDs über 90 Euro und auf Seite 2 alle SSDs unter 500 Euro abfragst, wirste vom Caching logischerweise nicht in dem Maße profitieren können.

In keinem Fall sollte man allerdings die oft im Internet angebotenen "Fuschlösungen" nehmen, die den Inhalt einer Abfrage hochintelligent in eine Textdatei schreiben, um diese dann später per file_get_contents wieder auszulesen und formatiert darzustellen - Das macht meiner Meinung nach eine DB überflüssig.

lg

[Shink]

Die Daten aus der Datenbank könnten sich beim nächsten Zugriff ändern. Je nach deiner Anwendung kann das erwünscht sein (Daten sind ja dann aktueller) oder auch zu Unsinn führen (z.B. man geht auf eine Seite die es nicht mehr gibt etc.)

[Berni]

Ein Array bleibt ja nach dem Seitenaufruf nicht bestehen. Somit wäre das Caching ja nur für die aktuelle Seite und da sollte es gut kontrolliebar sein, ob sich was ändert.
Abgesehen davon halte ich davon aber auch nichts. In der Regel wirst du die selbst gecacheten Daten ja dann Filtern müssen (also im Grunde Abfragen nachbilden) und daher wird sich das performancemäßig dann kaum lohnen. Und ich glaube auch nicht, dass du einen Webshop mit dermaßen vielen Usern hast, dass da eine Optimierung überhaupt groß nötig ist.
Wichtig ist halt sauber zu programmieren und die Schlüssel in der Datenbank korrekt zu setzen. Gut zu wissen ist auch, wie der Querycache von MySQL genau funktioniert. Dieser wirft nämlich Queries aus dem Cache sobald sich an der Tabelle etwas ändert. Bei Usertabellen z.B. bringt er also fast nichts während bei Artikeln (insofern sich diese kaum ändern) er sehr viel bringt. Aber auch ohne diesen Cache ist MySQL in der Regel ziemlich schnell...

[The_Invisible]

ähm, bei 50 artikel würde sich für mich die frage da gar nicht stellen.

das ist für ne db ja gar nichts, bei unserem mailserver mit so 200 queries pro sekunde lächelt die db auch nur, bei 50 artikeln lädt die datenbank nach einiger zeit ja nur mehr aus dem cache.

lieber zb die schleifen im programmcode optimieren, falls du so sachen hast wie pro schleifendurchlauf zusätzliche queries für einen artikel zu machen die man eigentlich in einer einzigen abfrage mit joins machen könnte oä.

mfg

[Der_Donnervogel]

Daten aus einer Datenbank in einer Webumgebung zwischenzuspeichern ist generell mit Vorsicht zu genießen. Man muss in diesem Fall wirklich sicher sein, dass die Datenbank nur von dieser einen Applikation genutzt wird (auch in Zukunft) oder genau wissen was man tut. Ansonsten kann man unangenehme Probleme mit inkonsistenten Daten bekommen. Sobald man die Daten zwischenspeichert verzichtet man nämlich auf die Synchronisierung durch die Datenbank. Wenn dann mehr als eine Applikation auf die Datenbank zugreift muss man selbst dafür sorgen, dass immer mit den aktuellen Daten gearbeitet wird und nicht irgendwelche veralteten Daten im Cache vom Programm sind.

Deshalb würde ich sofern nicht triftige Gründe dagegen sprechen die Datenverwaltung in der Datenbank belassen. Auch wenn MySQL sicher nicht die beste und performanteste Datenbank ist reicht sie für so etwas völlig aus. Im Normalfall kann man nicht viel falsch machen wenn man der Datenbank die Arbeit überlässt. Das einzige was man wirklich auf jeden Fall vermeiden sollte, ist die Connection nach jeder SQL-Query zu schließen und sie dann wieder zu öffnen. Das kostet richtig Performance. :ugly: