TTabels sind gut für fileorientierte "Datenbanken" (
Access/
Paradox/DBase etc), bei denen also keine Service-Programm auf einem Rechner läuft und die Kontrolle über die Daten hat. Bei "echten" Datenbanken (Interbase/Oracle/MS-
SQL/
MySql etc.) haben sie meines Erachtens nix verloren (Niemand, der 'nen Hammer hat, benutzt 'ne Säge zum Nageln, auch wenn's zur Not gehen würde
).
Filtern.
Mit dem Begriff Filtern kann ich nicht soviel anfangen. Er taucht hier immer wieder im Forum auf und ich denke, das dies von der Property "Filtered" der TTable herrührt. Da ich TTable noch nie auch nur mit dem Ar*** angeguckt habe, kann ich es nicht mit Bestimmtheit sagen, aber ich denke, das dies auf eine Client-seitige Filterung der Antwortdatenmenge hinausläuft, was wiederum performance-mäßig betrachtet der absolute Schwachsinn wäre (Server sendet ungefilterte DatenMenge an den Client, was dauert und das Netz belastet, und Client übernimmt dann den Job des Servers - das ist natürlich bei filebasierten "Pseudo-
DB's" nicht anders möglich, bei serverbasierten allerdings ein Schmarrn). Deshalb kann es schon sein, das hier im Forum an der einen oder Anderen Stelle vor dem "Filtern" gewarnt wurde.
Gegen den Einsatz von Einschränkungen (Where-Klauseln) im
SQL-Statement ist dagegen nichts einzuwenden - im Gegenteil. Die Where-Klausel führt ja schon bei der Selektion der Daten auf dem Server zu Geschwindigkeitsvorteilen, da die Ergebnisdatenmenge beschränkt und damit verkleinert wird.
Gruß