Auch mit der
BDE werden keine 17k Records geladen und im Grid angezeigt, sondern nur immer soviele wie sichtbar sind. Wegen der direkten Adressierung über die RecNo und die Tatsache, daß die Tabelle physikalsich als Datei im Zugriff ist, kann die
BDE da halt sehr schnell positionieren.
Die Rückgabemenge einer
SQL-Abfrage muss aber erstmal erzeugt werden, um darin zu navigieren. Deswegen ist bei einer
SQL-
Query mit 17k Records das
Open; Last;
deutlich langsamer als bei der
BDE, für die das am Ende lediglich ein FileSeek ist. Auch das seitenweise durchblättern der 17k Datensätze (aber wer will das schon) ist mit der
SQL-
Query nicht wesentlich langsamer, wenn man nicht beim Open schon alle Datensätze abruft, sondern nur soviele, wie ins Grid passen. Bei FireDAC z.B. würde man den FetchOptions.Mode auf fmOnDemand stellen (bzw. belassen).
Die
SQL-Abfrage hat aber genau dort einen entscheidenden Vorteil, wo ich die Datenmenge vorab schon einschränken kann und dem User nur das präsentiere, was er wirklich braucht. Das erfordert an manchen Stellen schon ein bisschen mehr Überlegung als nur ein Grid auf das Form zu schubsen und mit einer Tabelle zu verbinden.
Jemand hat das mal mit der Telefonauskunft verglichen (ja, ist schon 'ne Weile her):
SQL ist "Geben Sie mir bitte die Nummer von Heinz Müller, Heusengasse 14 in Köln".
BDE ist: "Lesen Sie mir bitte das Telefonbuch von Köln vor und wenn ich Stop sage, geben Sie mir die Nummer".