Und was spricht dagegen diesen "Workaround" nicht das beste und einfachste Möglichkeit zu nehmen?
Es ist einfach, es ist verständlich und es funktioniert ohne weiter Zusätzliche Implementierung.
Ich denke es spricht nichts dagegen, es war halt die Frage nach dem "was geht noch?".
Da DSG ja seine Anwendung gern recht kundenfreundlich gestaltet, wäre die Frage ja eher, was spricht wofür.
- Ein System, das mit exakten Angaben/Vorgaben arbeitet und entsprechend 100+(es gibt mehr) ausspuckt, nervt dezent, wenn es denn 101 sind oder 102 ..
- Ein System, was die Vorgaben nicht so genau nimmt und gleich die vorhandenen 109 Datensätze ausgibt, wäre cool
- Ein System, das genau 100 ausgibt, mit der Angabe "es gibt einige mehr" für +-25 und es gibt viel mehr für +-50 usw. wäre cool
Geschieht dies Ressourcen schonend, wäre es noch cooler und das ist ja neben dem Programmieraufwand, das einzige Argument, was gegen eine "schicke", "smarte" Lösung spräche. Wenn die Anwendung für so viel smartness 10 Sekunden zum "Rechnen" braucht, wird der Anwender darauf verzichten wollen.
In der Praxis macht es in vielen Fällen keinen Unterschied, ob noch mal ein separater Count mit der gleichen Where Clause abgefragt wird, warum also dann nicht? Bei einer "offenen Buchungsliste" wäre das allerdings dann vermutlich coolness am falschen Platz. Und bei manch "teueren" Abfragen ist man einfach froh, wenn sie halbwegs flott zurückkommen und stellt nicht noch weiter blöde Fragen.
Daneben gibt es noch technische Feinheiten wie Limit 100!=ab da hat sich niemand mehr Arbeit gemacht. Bspw. ..order by..limit 100 wird zumindest dafür sorgen, dass der Server garantiert die vollständige Menge bearbeitet. Gespart ist da also erstmal gar nichts, nur etwas Übertragung halt.