PHP DB Sucherergebnisse komplett in Session schreiben?

[dreivier]

Moin

Bin noch nicht so fit in PHP darum mal eine für euch Profis vllt. blö.. Frage.

Ich habe auf meiner Seite ein Suchformular, die Eingabe darin wird zu einem Php-Script
geschickt welches dann die DB danach dursucht.
Die Ergebnisse werden dann, jeweils 20 pro Seite (Blätterfunktion) ausgegeben. Soweit so gut.

Nun zu meiner Frage, ich habe in der Blätterfunktion z.B. 10 Links also 10 Seiten,
das heisst, jeder Link von 1-10 muss ja beim Klick immer ein query in der DB machen
damit ich die Seitenanzahl usw. ausrechnen, die Links erstellen kann...stresst das nicht
die DB? wäre es nicht besser alles aus der ersten query erst fertigzustellen also alle Links
erstellen, ausrechnen usw. und dann in eine Session zu speichern, die man dann zum
navigieren der Links nutzt?..dann würde man bei jeder Suche nur einmal die DB abfragen
und nicht 10 mal oder ist das egal?

 

[kim88]

Naja dafür wurden DBs entwickelt, die haben in der Regel kein grosses Problem mit vielen Anfragen. Solange die Abfragen sinnvoll formuliert sind.

Etwas vom absolut wichtigsten bei einer Webseite ist die Geschwindigkeit - wenn du bei einer Suchanfrage erstmal alle Einträge auslesen gehst ist die suche wohl schnarchlangsam.

wenn du nur 10 einträge ausgibst und das SQL Statement entsprechend formulierst (LIMIT, OFFSET) hat deine DB da keine grossen Schmerzen.

 

[RalphS]

Trugschluss. Die DB hat mehr Streß, wenn sie queries vollständig abdecken muß, obwohl das gar nicht notwendig ist.

Erwartetes Verhalten über die Zeit ist, daß das gesuchte Ergebnis Teil der ersten 50% Treffer ist. Also wird die DB um jene 50% entlastet.

genau dafür gibt es die Blätterfunktion. Ansonsten hätte man das auch auf eine Ergebnisseite schreiben können.

Dazu kommt, daß die session auch irgendwo gespeichert werden muß. Der Platz dort ist aber meistens eingeschränkt und es gibt ggfs auch ein architektonisches Problem (cf stateful/stateless und Clustering).

Von der Sache her würde das Modell also einfach den Ressourcenbedarf verschieben von DBMS über den webserver in Richtung Client mit zusätzlichem Overhead.

Wirklich schonend ist es aber nicht.

 

[dreivier]

@Ralph...ich mache das so das ich erst eine query auf die Eingabe mache um die Anzahl der gefunden Datensätze herauszubekommen, dann strike ich mir die Blätterfunktion zusammen und mache dann den query für die erste Ausgabe auf der Seite.

Was spricht dagegen wenn ich jetzt das erst query in eine Session schreib, dann habe ich die Anzahl der Datensätze permanent und brauch dann immer nur noch 1 anstatt 2 querys machen?

 

[floq0r]

In deinem Vorhaben fragst du alle Datensätze ab obwohl du nicht weißt ob der User überhaupt alle sehen will. Wie schon erwähnt gibt es Paginations unter anderem aus diesem Grund.
Sagen wir so: Da du solche Fragen stellst gehe ich frech davon aus, dass deine Abfrage so simpel und die Datenmenge so gering ist, dass es für heute übliche Ressourcen keinen Unterschied machen wird welche Variante du auswählst. Ohne Joins auf große Tables mit fehlenden Indizes läufst du da in keinen Engpass.

Eine gute Möglichkeit ist folgende:
Du stellst im Frontend fest ob Filter/Parameter geändert wurden, falls ja dann schickst du diese Info mit den Filtern ans Backend. Dort wird der Count der Ergebnisse abgefragt und ans Frontend übergeben. Damit baust du die Pagination auf. Wird anschließend nur die Seite gewechselt werden im Backend nur die Daten geladen weil der Count unverändert bleibt.

 

[Dalek]

Die Idee das man unnötige Arbeit macht wenn man jedes mal die gesamte Anzahl an Datensätzen zählt ist schon richtig. Aber das ist generell immer noch deutlich billiger als die volle Query die auch die Daten rausholt. Und du musst damit rechnen das in den meisten Fällen nur die ersten paar Seiten abgerufen werden, kaum jemand klickt sich durch hunderte oder tausende von Seiten durch.

Ganz grundsätzlich sind Datenbanken deutlich schneller als viele denken, wenn du nicht mindestens ein paar Hunderttausend Zeilen in der Tabelle hast spielt das alles noch keine große Rolle. Eine moderne Datenbank kann tausende von einfache Transaktionen pro Sekunde auf einem normalen Desktoprechner durchführen.

Die Anzahl der Datensätze (nicht die vollen Resultate) zu cachen kann durchaus sinvoll sein, aber das wird schnell sehr kompliziert. Der Cache muss invalidiert werden wenn neue Datensätze dazukommen oder geändert werden. Das würde ich nur machen wenn das Problem messbar ist, nicht einfach so.

Meine bevorzugte Lösung ist die Gesamtzahl gar nicht auszugeben bei pagination. Häufig ist sie gar nicht unbedingt interessant, und wenn man sie doch braucht kann man sie separat anfragen. Dann muss man das auch nicht pro Seite machen, sondern z.B. nur einmal am Anfang (das ist nicht völlig korrekt wenn Datensätze hinzukommen wenn man durchblättert, aber evtl. gut genug).

 

[andy_m4]

Die Ergebnisse werden dann, jeweils 20 pro Seite (Blätterfunktion) ausgegeben. Soweit so gut.

Für mich als Anwender sind solche Blätterfunktionen immer sch***e. Das stört nicht weiter, wenn das gesuchte Ergebnis unter den Top-Ergebnissen (also oben an) ist. Aber wenn ich dann weiter unten blättern muss, wird es sehr schnell sehr nervig weil man dann nicht einfach ohne weitere Interaktion querlesen oder die Suchfunktion des Browsers nutzen kann.

Leider ist diese dämliche Blätterfunktion sehr verbreitet. Das bedeutet aber nicht, das jeder den Fehler wiederholen muss. :-)

 

[Dalek]

Für mich als Anwender sind solche Blätterfunktionen immer sch***e. Das stört nicht weiter, wenn das gesuchte Ergebnis unter den Top-Ergebnissen (also oben an) ist. Aber wenn ich dann weiter unten blättern muss, wird es sehr schnell sehr nervig weil man dann nicht einfach ohne weitere Interaktion querlesen oder die Suchfunktion des Browsers nutzen kann.

Leider ist diese dämliche Blätterfunktion sehr verbreitet. Das bedeutet aber nicht, das jeder den Fehler wiederholen muss. :-)

Wie soll das denn sonst funktionieren wenn man Tausende von Datensätzen hat? Die kann man nicht alle an den Browser schicken und dort auch noch rendern.

Ich würde persönlich eher 50-200 Elemente pro Seite ausgeben (hängt aber sehr stark von der Anwendung ab), aber generell ist Pagination nicht etwas das man vermeiden kann.

Es gibt noch Endlosscrollen, aber das hat auch einige Nachteile und z.B. mit dem Browser suchen kann man da auch nicht.

 

[andy_m4]

Wie soll das denn sonst funktionieren wenn man Tausende von Datensätzen hat? Die kann man nicht alle an den Browser schicken und dort auch noch rendern.

Der Witz ist ja, das Webseiten heute gar nicht langsam sind wegen dem eigentlichen Nutzcontent. Die meisten Webseiten heutzutage sind langsam, weil der tonnenweise irgendwelche Scripts und Mediendaten geladen werden.

Anyway. Auch das Problem lässt sich lösen. Wie gesagt. Entweder ist das gesuchte Ergebnis schon unter den Top-Links oder ich muss halt querlesen.
Das heißt, Du kannst es ja gerne machen das Du von mir aus nur die Top-10, Top-20 ausgibst. Die sind dann auch fix da und wenn dann das Gesuchte dabei ist, dann ist ja auch alles gut.
Wenn ich weitere Ergebnisse benötige dann will ich aber nicht blättern. Dann soll es die Möglichkeit geben den Rest mit einmal zu laden.
Was spricht denn dagegen unter der Ergebnisliste einen Button zu packen a-la
"die restlichen 1200 Ergebnisse auch anzeigen"

Dann kann ich mir überlegen: Will ich das oder formuliere ich ggf. meine Suchanfrage um. Oder ich lade eben alles und nehme dann in Kauf das es länger dauert.
Aber dieses Blättern ist völlig sinnfrei.

Was man vielleicht noch alternativ machen könnte ist dieses nachladen at scrolling. Das heißt, umso weiter man nach unten scrollt umsehr mehr wird per AJAX die Ergebnisliste ergänzt. Dann hat man zwar auch nicht die Suchmöglichkeit via Strg-F aber wenigstens nicht diese Blätterei wo man dann auch noch eine Schaltfläche treffen muss.

 

[GroMag]

wenigstens nicht diese Blätterei wo man dann auch noch eine Schaltfläche treffen muss.

Ist aber nicht überall sinnvoll. Angenommen, jemand will sich ein Bookmark setzen, wo er Eintrag 142 haben will. Geht bei dem Endlos scrolling nicht. Da muss man immer vorn anfangen.

 

[andy_m4]

Ist aber nicht überall sinnvoll.

Was wo sinnvoll ist sicher auch vom konkreten Einzelfall ab. Ich merk bloß immer, das mich diese Blätterei in der Regel nervt und ich hab nicht einen Fall parat, wo ich froh bin das ich in dem Fall blättern konnte.

Angenommen, jemand will sich ein Bookmark setzen, wo er Eintrag 142 haben will.

Das Beispiel ist aber sehr an den Haaren herbeigezogen.
Wenn ich ein Bookmark setze will ich ja nicht die Page der Ergebnisliste wo die 142 ist.
Da klick ich die 142 an und speichere mir dann den Eintrag direkt.

Aber vielleicht verstehe ich auch einfach Dein Szenario nicht.

 

[RalphS]

Das Ziel ist ja auch nicht, blättern zu müssen. Die Idee ist, daß man dem Anwender sein Gesuchtes innerhalb der ersten X Treffer liefern kann und daß diese ersten X Treffer dann die erste Ergebnisseite bilden.

Je nach Kontext mag dafür 5 results per page passen, sagen wir auf der Suche nach Adressen. Oder 50 rpp für eine breitere Suche.

Nicht minder wichtig ist es, dem Anwender eine (variable) Ordnung bereitzustellen. Alles nur alphabetisch und es geht schief und der Anwender ist bald frustriert.

Klar, da kommt es dann drauf an, ob man überhaupt die Möglichkeit hat, die Ergebniskonfiguration anzupassen - und auf welche Weise --- und ob man da selber Hand anlegen kann (eigener Suchdienst) oder nicht.

In allen Fällen gilt, wenn ich den Anwender mit Hunderttausenden Ergebnissen erschlage, weil der nach "alles was mit A losgeht" gesucht hat, dann tu ich weder ihm noch mir einen Gefallen.

 

[andy_m4]

Die Idee ist, daß man dem Anwender sein Gesuchtes innerhalb der ersten X Treffer liefern kann und daß diese ersten X Treffer dann die erste Ergebnisseite bilden.

Klar ist das das Optimum. Darüber bestehen ja auch keine zwei Meinungen. Aber wenn es halt mehr als 10 oder 20 Ergebnisse gibt, dann ist das "Blätterangebot" eher unpraktisch.

Klar, da kommt es dann drauf an, ob man überhaupt die Möglichkeit hat, die Ergebniskonfiguration anzupassen - und auf welche Weise --- und ob man da selber Hand anlegen kann (eigener Suchdienst) oder nicht.

Ja. Finde ich auch.

In allen Fällen gilt, wenn ich den Anwender mit Hunderttausenden Ergebnissen erschlage, weil der nach "alles was mit A losgeht" gesucht hat, dann tu ich weder ihm noch mir einen Gefallen.

Naja. Aber das "mit Suchergebnis erschlagen" geht auch nicht dadurch weg, indem man ihm eine Blätterfunktion anbietet. Die hilft ihm da nämlich nicht weiter.

 

[RalphS]

Wie jetzt? Da fehlt mir grad die Brücke. Ohne Blätter hieße doch, dem Anwender die restlichen Ergebnisse gänzlich vorzuenthalten, oder nicht? 🤔

 

[KitKat::new()]

Ohne Blätter hieße doch, dem Anwender die restlichen Ergebnisse gänzlich vorzuenthalten, oder nicht? 🤔

Ohne Blättern heißt die Seite fügt automatisch weitere Ergebnisse unten an der Liste hinzu - so, dass ich erst ein Ende sehe, wenn es keine Ergebnisse mehr gibt.
Nennt man auch "Infinite Scrolling"

 

[andy_m4]

Ohne Blätter hieße doch, dem Anwender die restlichen Ergebnisse gänzlich vorzuenthalten, oder nicht? 🤔

Von Ergebnis vorenthalten war ja auch gar nicht die Rede. Sondern davon, das blättern im Allgemeinen eine schlechte Möglichkeit ist und es bessere Varianten gibt ihm die restlichen Ergebnisse zu präsentieren, wie beispielhaft in dem Beitrag über diesen dargestellt.

Wurde aber eigentlich alles bereits in darüberliegenden Beiträgen geklärt. Deshalb bin ich etwas verwundert über Deinen Einwurf.

 

[dreivier]

Ohne Blättern heißt die Seite fügt automatisch weitere Ergebnisse unten an der Liste hinzu - so, dass ich erst ein Ende sehe, wenn es keine Ergebnisse mehr gibt.
Nennt man auch "Infinite Scrolling"

Geht aber nur mit JS, hast du kein JS aktiviert bekommst du je nachdem wie man den Rest programmiert hat, nix presentiert oder alles aufeinmal, was deinen Browser ggf. abstürzen lässt.
Man kann natürlich beides machen und die JS Sache als Komfortfunktion anbieten wenn der Benutzer JS auch freigegeben hat, aber JS als Vorraussetzung..hmm nee ist nicht mein Ding weil es gibt genug Leute die schalten JS ab, alleine schon wegen der ganzen Trackinggeschichten, Werbung und und und.

Abgesehen, ich sehe nichts schlimmes an einer Blätterfunktion, wenn die Suche vernünftig programmiert/durchdacht ist und dem Suchendem vernünftige Ergebnisse liefert ist doch alles grün.