Firebird - Suche beschleunigen

[Der Jan]

Hallo,

ich hab da mal wieder ne Frage :) Wie kann ich die Suche in einer Firebird-DB / pFIBDataset bescheunigen?
Folgende Situation: Eine Tabelle mit Kundendaten, in der möchte ich nach einem Kunden anhand seiner Kundennummer suchen. Das Feld 'KUNDEID' ist vom Typ INTEGER und ist der PK, hat also einen Index.
Wenn ich jetzt suche:

Delphi-Quellcode:

//Variante 1:
with dsetKunde do begin
  Active := true;
  DisableScrollEvents;
  Locate('KUNDEID', KuNr, []);
  EnableScrollEvents;
end;

//Variante 2:
with dsetKunde do begin
  Filter := 'KUNDEID' + KuNr;
  Filtered := true;
  Active := true;
end;

dann dauert das ewig. Zur Zeit hab ich mehr oder weniger nur Testdaten drinne, so etwa 30000 Datensätze. Das Suchen dauert jedoch mal ganz locker 15-20 Sekunden im ungünstigen Fall. Es werden im Endeffekt bestimmt 10-15 mal so viele Datensätze sein, da ist so eine lange Suchzeit nicht akzeptabel.
Gibts es da noch irgendwelche Tricks, das ganze schneller zu machen?

[mkinzler]

Der Index bringt die hier nichst, da du ja nur loakl filterst. Verwende eine gefilterte Abfrage.

[Hansa]

Gib mal mehr Infos. Es wird ja wohl nicht 15 Sek. dauern einen einzigen Datensatz zu finden. Der muß sofort da sein. Und mit sofort meine ich sofort ! :mrgreen: Geht es vielleicht um ein Grid ? Egal wie : poste mal das Select-Statement.

[webcss]

Grundsätzlich würde ich auf Dataset-Filter verzichten! Mach ein select statement daraus, damit hast du auf dauer mehr spass.
Eine Suche über Dataset.Locate läuft immer sequentiel ab vom ersten bis zum letzten Datensatz. Ab einer gewissen menge an daten dauerts halt a biserl.
Lass also besser Firebird die Suche machen, via query. Nebeneffekt: Deine Daten sind immer auf dem neusten Stand, etwa bei mehreren Clients mit vielen Änderungen!

[Der Jan]

Ich habs inzwischen so gemacht, das ich einfach das SelectSQL-Statement erweitere. Da gehts dann auch fix :)
Gibt es dennoch ne möglichkeit, die lokale Suche im Dataset zu bescheunigen? Ich kann mir nicht vorstellen, das die Suche DB-seitig in Sekundenbruchteilen abläuft und im Dataset so ewig dauert.

@Hansa: Ganz normales Statement, nix besonderes:

SQL-Code:

SELECT 
  K.KUNDEID,
  K.ANREDEID,
  K.TYP,
  K.NAME,
  K.VORNAME,
  COALESCE(K.NAME || ', ' || K.VORNAME, '-') AS FULLNAME,

/* undsoweiter */
FROM
  KUNDE K

[mkinzler]

Der Grund, warum ein serverseitiges Filtern schneller ist, das hierbei auf die Indices zugegriffen werden kann und nur die benötigten Daten an den Client übertragen werden. Beim loaklen Filtern wird der komplette datenbestand an den Client übertragen und dort (ohne Indices) gefiltert. Ich würde diesen Vorteil nutzen und auf eine clientseitige Filterung wenn möglich verzichten.
Sonst wäre vielleicht über den Einsatz einer cachable Datenmenge wie z.B. TClientDataSet nachzudenken.

[webcss]

Oder zum Beispiel ein MemDataset, oder noch flexibler, ein eigenes Object auf Basis TList.

[alzaimar]

Normalerweise sollte es so lokal auch schnell genug gehen:

Delphi-Quellcode:

MyDataSet.DisableControls;
Try
  SuchenUndFinden
Finally
  MyDataSet.EnableControls;
End;

Zitat:

Zitat von Der Jan

...Ich kann mir nicht vorstellen, das die Suche DB-seitig in Sekundenbruchteilen abläuft und im Dataset so ewig dauert.

Na ja, ein DB-Server verwendet hochperformante und handoptimierte Algorithmen für die Suche, optimiert Suchbäume, hat einen sehr effizienten Cache. Eine lokale Suche ist i.A. linear ('von vorne nach hinten') oder mit einer Binärsuche implementiert. Das Suchen in einem DB-Index ist in fast konstanter Zeit möglich, sofern der Index richtig gesetzt ist. Das ist im Client nur unter Verwendung der B-Bäume oder von Hashmaps möglich. Wer sowas nicht im Portfolio hat, ist also mit einem DB-Server besser bedient. Und auch wenn man mit Hashmaps arbeitet, müsste man die Daten ja erst dort rein laden.

Es ist auch, sagen wir, suboptimal (oder schlicht und einfach dämlich), die gesamte Tabelle vom Server zum Client zu schaufeln, um dann nach einem Datensatz zu suchen. Insofern ist es einfach klüger, die Suche dem zu überlassen, der das am Besten kann: Dem DB-Server.

Das Wichtigste ist jedoch, die Indizes richtig zu wählen. Zu viele verlangsamen die Datenmanipulation, zu wenige, oder an den falschen Stellen, machen aus dem DB-Ferrari eine lahme Ente.

[mquadrat]

Dem ist nichts mehr hinzuzufügen ;)

Ein weiteres Argument gegen das Transferieren der kompletten Tabelle wäre noch die Netzwerklast, die man unnötigerweise erzeugt. Bei einem Betrieb mit so vielen Kundenndatensätzen, ist auch anzunehmen, dass es recht viele Sachbearbeiter gibt...

[Der Jan]

Ok :)

Ich danke euch für die vielen Hinweise. Leider entwickle ich die Software nur weiter, kann also an manchen Stellen nicht so, wie ich gerne wöllte. Aber ich werd dem Teil schon das Rennen beibringen :)