Scope und Filter [ERLEDIGT]

[Koverhage]

Habe folgendes Problem ich setze einen Scope auf Kundennummer Datei hat auch den Index Kundennummer
Jetzt möchte ich innerhalb dieses Scopes einen Filter setzen, z.B. auf Zahlungsart, für welche es keinen Index gibt.
Das ganze dauert ewig, so als wenn man meinen könnte, das es keinen Scope gibt.
Was kann ich da tun, ohne einen neuen Index zu erstellen ?

[georg]

Hallo, Klaus -


a) nix
b) einen entsprechenden Index erzeugen
c) SQL verwenden

[brandelh]

Hallo Klaus,

Filter und Index vertragen sich nicht !
Ich ersetze den Filter durch eine Abfrage oder DBLOCATE() DBCONT()

statt:

Code: Alles auswählen

set scope ...
set filter to &(cFilterbedingung)
go top
do while ! eof()
    Aktion()
enddo

etwa so

Code: Alles auswählen

set scope ...
go top
do while ! eof()
    if &(cFilterbedingung)
       Aktion()
    endif
enddo

oder so

Code: Alles auswählen

set scope ...
bFilter := &(cFilterbedingung)
DbLocate(bFilter)
do while found() .and. ! eof() // sicher ist sicher ;-)
     Aktion()
     DbContinue() 
enddo

Wenn der SCOPE Bereich ausreichend eingrenzt (also < 100 Treffer liegt) geht das so sehr schnell.

[Tom]

Filter und Index vertragen sich nicht !

Wer sagt das? Ein Index ändert zunächst einmal nur die Reihenfolge der Datensätze. Ein Filter bewirkt, dass bei jeder Navigation die Filterbedingung geprüft wird, um dann die Navigation fortzusetzen, wenn das nicht der Fall ist. Ein geöffneter führender Index mag das im Mikrosekundenbereich verlangsamen, aber die Behauptung, dass sich das nicht "verträgt", ist blanker Unsinn. Wenn ich eine Million Datensätze habe und diese nach einem bestimmten Ausdruck filtere, ist das genauso langsam oder schnell mit oder ohne Index - es hängt davon ab, wo die Treffer sind. Grundsätzlich wird jeder Datensatz evaluiert, den ich "anfasse", und es ist völlig schnuppe, ob ein Index geöffnet ist oder nicht.

Ich arbeite viel mit Scopes und Filtern, das ist die einzige Konstellation, in der Filter bei großen Tabellen überhaupt noch zum Einsatz kommen. Ein Scope sitzt also beispielsweise auf der Kundennummer bei Aufträgen, und ich filtere alle, die einen höheren Auftragswert als € 10.000,-- haben. Das ist um den Faktor 10 - mindestens - schneller, als würde ich alle Aufträge nach Kundennummer und Summe filtern. Mindestens. Der Scope bewirkt eine - schnelle - Einschränkung über den Index, und zusätzlich werden die Datensätze bei der Navigation evaluiert. Und zwar rasant.

Wenn man mit Filtern arbeitet und sich - beispielsweise in einem Browse - stetig in den Datensätzen bewegt, sollte man SMARTFILTER auf ON setzen. Dabei merkt sich die Engine nach und nach alle Datensätze, die der Filterbedingung genügen, und prüft diese dann nicht mehr. Das kann man auch über ein eigenes Datenbankobjekt und ein simples, sich bei der Navigation füllendes Array nachstellen. Ändert sich vermeintlich an der Datenbasis etwas, löst man ein DbRefresh() aus, das löscht die "gemerkten" Datensätze. Ein Browse mit Scope und Filter, das aus einer Million Datensätze etwa hundert anzeigt, ist dadurch dann - nach den ersten Navigationen - so schnell, als würde die Tabelle nur aus diesen hundert Datensätzen bestehen.

[Koverhage]

Habe jetzt einen neuen Index hinzugefügt.
Vielleicht schaffe ich es ja mal von NTX auf CDX umzustellen

[brandelh]

Hallo Tom,

du hast insoweit recht, dass auch ein FILTER flott ist, solange der SCOPE die Anzahl der zu durchsuchenden Datensätze deutlich (im Bereich bis 100 oder so) einschränkt.

Ein Index ändert zunächst einmal nur die Reihenfolge der Datensätze.
Ein Filter bewirkt, dass bei jeder Navigation die Filterbedingung geprüft wird, um dann die Navigation fortzusetzen, wenn das nicht der Fall ist.

da stimme ich dir voll zu ...

Ein geöffneter führender Index mag das im Mikrosekundenbereich verlangsamen ...

pro Datensatz

Wenn ich eine Million Datensätze habe und diese nach einem bestimmten Ausdruck filtere, ist das genauso langsam oder schnell mit oder ohne Index

Genau da irrst du. Eine DBF OHNE INDEX wird "am Stück" sequentiell eingelesen und das ist wesentlich schneller, als wenn je Datensatz zunächst die Index-Datei gesperrt interpretiert und danach ein winziger Block (Datensatz) aus dem Stück geschnitten wird. Je nach DBF Größe kann zwar der Cache noch was richten, aber wenn wir bei 1.000.000 Datensätzen sind richtet er nichts mehr. Ob der Anwender das Ergebnis als akzeptabel empfindet hängt sehr von der Verteilung der Daten und seiner Nutzung ab.

Das mit dem Smartfilter ist komplett an mir vorbei gegangen ...