Scope und Filter [ERLEDIGT]
Moderator: Moderatoren
- Koverhage
- Der Entwickler von "Deep Thought"
- Beiträge: 2470
- Registriert: Fr, 23. Dez 2005 8:00
- Wohnort: Aalen
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Scope und Filter [ERLEDIGT]
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 ?
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 ?
Zuletzt geändert von Koverhage am Do, 25. Apr 2013 15:58, insgesamt 1-mal geändert.
Gruß
Klaus
Klaus
-
- Der Entwickler von "Deep Thought"
- Beiträge: 2827
- Registriert: Fr, 08. Feb 2008 21:29
- Hat sich bedankt: 96 Mal
- Danksagung erhalten: 13 Mal
Re: Scope und Filter
Hallo, Klaus -
a) nix
b) einen entsprechenden Index erzeugen
c) SQL verwenden
a) nix
b) einen entsprechenden Index erzeugen
c) SQL verwenden
Liebe Grüsse aus der Eifel,
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
Georg S. Lorrig
Redakteur der Wiki des Deutschprachigen Xbase-Entwickler e.V.
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Scope und Filter
Hallo Klaus,
Filter und Index vertragen sich nicht !
Ich ersetze den Filter durch eine Abfrage oder DBLOCATE() DBCONT()
statt:
etwa so
oder so
Wenn der SCOPE Bereich ausreichend eingrenzt (also < 100 Treffer liegt) geht das so sehr schnell.
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
Code: Alles auswählen
set scope ...
go top
do while ! eof()
if &(cFilterbedingung)
Aktion()
endif
enddo
Code: Alles auswählen
set scope ...
bFilter := &(cFilterbedingung)
DbLocate(bFilter)
do while found() .and. ! eof() // sicher ist sicher ;-)
Aktion()
DbContinue()
enddo
Gruß
Hubert
Hubert
- Tom
- Der Entwickler von "Deep Thought"
- Beiträge: 9367
- Registriert: Do, 22. Sep 2005 23:11
- Wohnort: Berlin
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 361 Mal
- Kontaktdaten:
Re: Scope und Filter
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.Filter und Index vertragen sich 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.
Herzlich,
Tom
Tom
- Koverhage
- Der Entwickler von "Deep Thought"
- Beiträge: 2470
- Registriert: Fr, 23. Dez 2005 8:00
- Wohnort: Aalen
- Hat sich bedankt: 102 Mal
- Danksagung erhalten: 3 Mal
- Kontaktdaten:
Re: Scope und Filter
Habe jetzt einen neuen Index hinzugefügt.
Vielleicht schaffe ich es ja mal von NTX auf CDX umzustellen
Vielleicht schaffe ich es ja mal von NTX auf CDX umzustellen
Gruß
Klaus
Klaus
- brandelh
- Foren-Moderator
- Beiträge: 15697
- Registriert: Mo, 23. Jan 2006 20:54
- Wohnort: Germersheim
- Hat sich bedankt: 66 Mal
- Danksagung erhalten: 33 Mal
- Kontaktdaten:
Re: Scope und Filter
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.
Das mit dem Smartfilter ist komplett an mir vorbei gegangen ...
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.
da stimme ich dir voll zu ...Tom hat geschrieben: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.
pro DatensatzTom hat geschrieben:Ein geöffneter führender Index mag das im Mikrosekundenbereich verlangsamen ...
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.Tom hat geschrieben:Wenn ich eine Million Datensätze habe und diese nach einem bestimmten Ausdruck filtere, ist das genauso langsam oder schnell mit oder ohne Index
Das mit dem Smartfilter ist komplett an mir vorbei gegangen ...
Gruß
Hubert
Hubert