Kurzes Pro & Kontra für Inhaltsfilter und Pagination-art

[Paykoman]

Hallo Form,

ich arbeite gerade an einem Auktion-Projekt und setze da gerade das Filtern und und Pagination der Auflistung von Auktionen um.
Da bin ich jeweils auf 2 Arten gekommen wie man es machen könnte und hätte gern von erfahreneren Usern ein Pro und Kontra zur Umsetzung.

1) ich kann die vollständige Liste mit data-attribute laden und mit JS die Filter anwenden das entsprechende Elemente ausgeblendet werden. Gilt auch bei Pagination.

2) Die andere Art wäre bei jeder Änderung am Filter ein Formular zu senden und den Server die Arbeit aufbrummen nur die passenden Auktionen zu laden. Gilt dann auch wieder bei Pagination.

Was mir spontan dazu einfällt:

1) Kontra: hat längere Ladezeiten, hohe Last des Clients wenn da 1000 Counter im Hintergrund laufen
Pro: einfachere Querys, weniger Last für den Server

2) Dann eben genau umgekehrt.

Bin mir da echt unschlüßig wie ichs umsetzen soll, Feedback würde mir echt weiterhelfen.

MfG: Paykoman

::EDIT::
Da fällt mir gerade ein, zur ersten Variante könnte ich den Filter entsprechend erweitern das man das Limit selber einstellen kann, default = 100 und dann einfach ein Dropdown in hunderter Schritte. Wenn dem User noch kein passendes Angebot geliefert wurde, könnte er das Limit selber erhöhen so würde statt 100 eben 200 Auktionen geladen. Hätte zum Vorteil das der Server nicht ständig komplett alle aus einer Kategorie laden muss und die Ladezeit zu mindestens zu Beginn schön schnell ist.

[hellbringer]

Und Beitrag 3 ist wenn iches richtig gesehen habe ne API (Ersatz für REST) etc. das ist doch eigentlich was völlig anderes...

Nein, das ist eigentlich genau das, das man für sowas verwendet. Eine API, die dynamisch Daten ausliefern kann, die anschließend der Browser anzeigt.

[Paykoman]

Stimmt aber auch hier kann mit JS wieder eine Prüfung bauen, wenn die Seite geblättert wird, kann man einen timestamp der beim laden gesetzt wurde mit einem jetzigen vergleichen und ggf. die Seite neuladen und schwupps hat er die Liste aktuell.

Sieht aber so aus als würde ich auch nen Websocket hinzubauen der kann die Liste dann auch aktuell halten.

Das mit den Counter war so angedacht, weil das Skript das ich einsetzte sekündlich das jeweilige Dom-Element anspricht und das würde sich dann mit der hohen Anzahl an Auktionen schon argh den client (Browser) belasten oder?

[VPh]

Das Problem bei einer rein JavaScript-Seitigen Filterung und Pagination ist ja, dass neue Datensätze nicht in die Anzeige eingeschleust werden. Allein deshalb macht es für mich schon Sinn mit einer Aktion des Users mal den Datenbestand abzufragen.
"User Henry öffnet früh am Morgen die Auktionsliste; er geht kurz einkaufen, zum Arzt und das Auto waschen... als er sich an den PC setzt und in der Auktionsliste vor und zurück blättert wundert er sich 'na nu, seit 5 Stunden keine neuen Auktionen?'."

1) Kontra: hat längere Ladezeiten, hohe Last des Clients wenn da 1000 Counter im Hintergrund laufen

Das mit den "1000 Counter" verstehe ich nicht ganz.

[Paykoman]

Ja habe aber ja fix den php part dabei gemischt, damit man erkennt was aus der DB geladen wird...
Das es HTML ist is mir auch klar

Und Beitrag 3 ist wenn iches richtig gesehen habe ne API (Ersatz für REST) etc. das ist doch eigentlich was völlig anderes...

[protestix]

Das ist kein Datensatz. Datensätze kommen aus einer Datenbank. Das was du zeigst ist HTML und damit die Ansicht im Browser, das kannst du durchaus dynamisch mit Javascript erstellen lassen, wenn du das möchtest.

Hellbringer hat in Beitrag #3 ja schon darauf hingewiesen wie man das idealerweise macht, den Hintergrund dazu erfährst du auf Wikipedia.

[Paykoman]

Ja, wenn du nicht in Deutschland lebst geht das sogar schnell, aber es soll ja Regionen geben, die kein Megabit Internet haben und wenn dann der Titel im Durchschnitt nur 50 Byte beträgt, dann überträgst du glatt 5 Megabyte nur an Daten aus dem DBMS ohne Schnickschnack drumherum. Warum sollte man so was wollen?

Stimmt, ist natürlich auch ein wichtiger Aspekt!

[Paykoman]

Danke danke, das ist alles schon recht guter Input!

Zur Datenmenge, ja die ist in der Tat gering...

Ein Datensatz schaut so aus:

<section id="aucList"> <!-- Container der Liste -->
    foreach( $aucList as $auction ){
        <div class="cal" data-filter-a="<?php echo $auction['a']; ?>" data-filter-b="<?php echo $auction['b']; ?>" data-filter-c="<?php echo $auction['c']; ?>" data-filter-d="<?php echo $auction['d']; ?>">
            <div style="background-image: url('<?php echo $auction['img']; ?>');"></div>
            <div class="aucListData">
                <div class="clamp"><a href="#"><?php echo $auction['titel']; ?></a></div>
                <div>
                    <p class="clamp" data-clamp="5"><?php echo $auction['desc']; ?></p>
                    <span><?php echo $auction['country_iso']; ?>- <?php echo $auction[''plz]; ?></span>
                </div>
                <div class="auCtn" data-end="<?php echo $auction['date_end']; ?>"></div>
                <div><?php echo $auction['lastBit']; ?></div>
            </div>
        </div>
    }
</section>

Die 4 data-filter entspricht dann auch der DB-Tabellen-Spalte (halt als dummy), das wäre dann eben ausschlaggebend wo JS entscheidet das element aus oder einzublenden.

[protestix]

Tital der Auktion brauche um zu filtern, dann kann ich durchaus locker 100000 Auktionen direkt laden und danach in Echtzeit filtern

Ja, wenn du nicht in Deutschland lebst geht das sogar schnell, aber es soll ja Regionen geben, die kein Megabit Internet haben und wenn dann der Titel im Durchschnitt nur 50 Byte beträgt, dann überträgst du glatt 5 Megabyte nur an Daten aus dem DBMS ohne Schnickschnack drumherum. Warum sollte man so was wollen?

[Thallius]

Das funktioniert bei kleinsten Datenmengen. Bei größeren Mengen wird der Browser mit Daten zugeschi**en und geht bald in die Knie. Und es dauert sehr lange, bis alle Daten vom Server zum Client übertragen werden.

Auch wird die Performance wesentlich schlechter sein, außer du implementierst eine eigene Datenindizierung in JavaScript. Sowas kann der Datenbankserver halt schon sehr gut von Haus aus.

Kleinste Datenmengen ist hier hier aber sehr relativ. Vor allem hängt es stark von der Größe eines Datensatzes ab. Wenn ich zum Beipsiel nur den Tital der Auktion brauche um zu filtern, dann kann ich durchaus locker 100000 Auktionen direkt laden und danach in Echtzeit filtern (z.B. eine sehr schnelle Echtzeitfilterung wenn ich in ein Inputfeld etwas eintippe und dann direkt bei jedem Buchstaben suche. Das wird bei Variante 2 schon deutliche Verzögerungen bringen, während das in Variante 1 in weniger als 100ms erledigt ist und damit für den Benutzer nicht als Verzägerung spürbar.)

Wenn ich von vornehinein weiß, dass sich meine Anzahl Datensätze nicht großartig ändert (was in diesem Usecase wahrscheinlich nicht der Fall ist), dann kann ich mich durchaus für Variante 1 entschliessen. Ansonsten lieber auf Nummer sicher gehen und für die Zukunft programmieren mit Variante 2

Gruß

Claus

[hellbringer]

In der ersten Variante würde ja garkein LIMIT gesendet (wie vor dem Edit) und die ganzen Filter (preis, Umkreis etc) sind ja schwerwiegender als Pagination, darum ja dieser Post denn i.d.R. kann ich die Filterung auch von JS übernehmen lassen (ohne Limit und mit js-Pagination wären halt alle items vorhanden).

Das funktioniert bei kleinsten Datenmengen. Bei größeren Mengen wird der Browser mit Daten zugeschi**en und geht bald in die Knie. Und es dauert sehr lange, bis alle Daten vom Server zum Client übertragen werden.

Auch wird die Performance wesentlich schlechter sein, außer du implementierst eine eigene Datenindizierung in JavaScript. Sowas kann der Datenbankserver halt schon sehr gut von Haus aus.

[Paykoman]

Auf jeden Fall die 2. Variante.
Übergebe auch die letzte Id ab der du die Pagination starten willst, da Limit mit zunehmender Anzahl sehr langsam wird.

Danke schon mal, mir fehlen aber bissl die Pros & Kontras zum Filter

In der ersten Variante würde ja garkein LIMIT gesendet (wie vor dem Edit) und die ganzen Filter (preis, Umkreis etc) sind ja schwerwiegender als Pagination, darum ja dieser Post denn i.d.R. kann ich die Filterung auch von JS übernehmen lassen (ohne Limit und mit js-Pagination wären halt alle items vorhanden).

[hellbringer]

Idealerweise setzt man sowas als OData-API um:

http://www.odata.org/

[protestix]

Auf jeden Fall die 2. Variante.
Übergebe auch die letzte Id ab der du die Pagination starten willst, da Limit mit zunehmender Anzahl sehr langsam wird.