BDE vs. ADO - BDE bei DBase ist ca. 4-mal schneller !!!

[Günther Andeßner]

Ich verwende eine Tabelle zum Suchen eines Wertes und zum anschließenden Rückgebens eines anderen Wertes (z.B. Vornamen - Anreden)

Im Rahmen einer neuen Anwendung möchte ich diese Referenzen auf einen SQL-Server (ver. 7.0) legen und von mehreren Arbeitsstationen aus zugänglich machen. Vorher war die Referenz im DBF-Format. Struktur und Inhalt sind in beiden Fällen diesselbe.

In DBF habe ich über die TTable-Komponente mit GotoKey, bzw. GotoNearest gearbeitet, in ADO versuche ich es über Locate, die DBF ist aber ca. 4-fach schneller - was mache ich falsch, bzw. wie kann ich den Speed verbessern.

Dank, Günther

[Patrick Sack]

Hi,
<br>
<br>Indexe überprüfen und ggf. setzen.
<br>Wie sieht das SQL Statement aus?
<br>
<br>mfg
<br>P

[Günther Andeßner]

Indizes sind vorhanden, spielt aber in diesem Fall auch nicht wirklich eine Rolle (glaub ich zumindest).

Ich hole mir die Tabelle am Beginn der Funktion einmal rein (Cursor-Client), und such mir dann für eine sehr oft einen Wert raus - mit dem Locate-Befehl...

Zum besseren Verständnis:

Ich suche Vorname in einer Referenz um zu bestimmen, welches Geschlecht wer hat... und das ganze für 10.000 bis ein paar millionen Stück.

Mit DBase und der BDE schafft das Programm im Schnitt 1.800 bis 2.200 Datensätze / Sekunde, mit der Server-Variante und ADO nur 500 bis max. 650 Stk./Sek.

es kann irgendwie nicht am Server selber liegen (es ist zum Testen ein 2000er SQL-Server der lokal auf meinen Rechner ausgeführt wird)

Liegt es also nur daran, das ADO (sprich: OLE DB) mit diesem Locate-Befehl einfach sooo viel langsamer ist (wenn ja, gibt es da noch eine Alternative ??), oder bin ich von Haus aus zu blöde ???

mit den demütigsten Grüßen, Günthe

[Patrick Sack]

Hallo,
<br>
<br>also ich glaub ich verstehe es noch nicht ganz, aber...
<br>
<br>also ich suche in der tabelle Personen nach dem Feld Personen.Vornamen lese dann aus Personen.Anrede_ID den IDWert und suche dann in der Tabelle Anreden nach dem IDWert und habe dann zugriff auf die Anrede.Anrede?
<br>
<br>Dann erhalte ich eine Liste die wie folgt aussieht:
<br>Anrede Vorname
<br>Herr Hans
<br>Frau Simone
<br>
<br>richtig?
<br>
<br>mfg
<br>p

[Günther Andeßner]

<b>Richtig !!! </b&gt

[Patrick Sack]

Hi,
<br>
<br>Tabelle Personen:
<br>Personene_ID--Anreden_ID--Vorname ...
<br>---100----------1-----------Hans
<br>...
<br>---202----------2-----------Simone
<br>
<br>Tabelle Anreden:
<br>Anreden_ID--Anrede ...
<br>---1---------Herr
<br>---2---------Frau
<br>
<br>TADODataSet.SQLText := 'Select Anreden.Anrede, Personen.Vorname from Personen Join Anreden on Personen.Anreden_ID = Anreden.Anreden_ID Where <geeigneter Filter>';
<br>
<br>Liefert:
<br>Anrede--Vorname
<br>-Herr----Hans
<br>-Frau----Simone
<br>
<br><geeigneter Filter>
<br>sollte man einsetzten, wenn es zu lange dauert, da mir ja in der Liste alle Datensätze der Tabelle Personen gezeigt werden. Und das kann bei einer Anzahl > 100.000 schon länger dauern.
<br>
<br>mfg
<br>p

[Günther Andeßner]

uuuups, da hab ich mich doch ein bißchen unglücklich ausgedrückt:<br>

Ich weiß ja die Anreden_id in der Tabelle Personen noch gar nicht, die will ich ja herausfinden.<br>

Tabelle Personen:<br>

Personen_ID --- Anrede_ID -- Vorname -- blabla<br>
--100 ---------- ???? -- Patrick -- xxxxx<br>
--200 ---------- ???? -- Patrice -- xxxxx<br>
...<br>

Tabelle Vornamen:<br>
Suchbegriff --- Anrede_ID<br>
Patrick ------- 1<br>
Patriqué ------ 2<br>
Patrice ------- 2<br>
......<br>

Ich hab es großteils mit (schlecht) händisch erfaßten Daten zu tun und soll die Qualität steigern... ;-)<br>

Ich verwende dazu verschiedene (Fuzzy-)Vergleichmethoden und ermittle so die wahrescheindlichste Anrede_ID.<br>

Dank Dir recht herzlich für Dein Bemühen !!

[Patrick Sack]

Hi,
<br>
<br>habe das selber noch nicht gemacht, aber so oder so ähnlich sollte es gehen:
<br>
<br>Select P.Vorname,
<br>(Select V.Anrede_ID From Vornamen V Where DIFFERENCE(V.Suchbegriff, P.Vorname) = 4) as VermuteteAnrede
<br>From Personen P
<br>
<br>Zauberwörter sind hier <b>Difference</b> und <b>SoundEX</b>. Danach in der MS SQL Hilfe suchen, oder hier im Forum.
<br>
<br>mfg
<br>P

[Günther Andeßner]

Ist sicher einen versuch wert - <b>DANKE</b> <br>

- aber nach dem das Problem mit den Anreden eher noch das am einfachsten zu Vergleichensde ist, wird mir das mit dem Geschwindigkeitsverlust durch "locate" bei komplexeren Vergleichen bleiben.<br>
Denn wenn ich dich richtig verstanden habe, ersetzt mir diese DIFFERENCE nur meinen Vergleich - und verpflanze so die logik dahinter auf den Server (ob MS das sooo gut kann ???) ;-)<br>

mfg<br>

günthe

[Patrick Sack]

Hier im Forum:
<br>http://www.entwickler-forum.de/webx?128@@.ee6c551
<br>
<br>"(ob MS das sooo gut kann ???)"
<br>Weiß ich auch nicht. Aber ich denke mal der SoundEX Alg. den MS verwendet ist der gleiche, den auch Oracle, MYSQL usw. verwenden.
<br>
<br>Aber du hast recht. Habe gerade in mehreren Büchern mal nach gelesen und dort heißt es immer: "...ähnlich klingenden..." und einmal sogar "...ähnlich klingenden englichen Wörtern..."
D.h. das ist noch die Frage, ob man hier in Deutschland mit ruhigem Gewissen die SoundEX Funktion des jeweiligen Servers verwenden kann.
<br>Und bei Beispielen wie:
<br>SOUNDEX ('Smith'), SOUNDEX ('Smythe')
<br>Hören sich im deutschen nicht besonders ähnlich an. Oder nicht?
<br>
<br><b>@all:</b>
<br>Weiß das vieleicht jemand, ob es einen Unterschied zwischen SoundEX englichem Server und SoundEX Deutschem Server gibt?
<br>
<br>Wenn du dir sowas selber Programmieren willst und dann Delpi verwendest, dann würde ich nicht Locate verwenden, sondern ein Select Statement bastel, das mir das Locate "ersetzt". D.h. anstatt in meiner Ellen langen Liste an die Position mit Locate zu springen liefert mir das Select genau den einen daten Satz, den ich sehen will. Und das sollte schneller, als Locate sein.
<br>
<br>"wird mir das mit dem Geschwindigkeitsverlust durch "locate" bei komplexeren Vergleichen bleiben."
<br>Komplexe Vergleiche sollte man ohne hin wenn möglich in einer Stored Procedure auf dem Server verwirklichen, um einem "Geschwindigkeitsrausch" näher zu kommen. (Server hat meistens mehr Power als der Client, der Flaschenhals Netzlast wird umgangen)
<br>
<br>mfg
<br>p

[Günther Andeßner]

Danke für die Tipps<br>
die SoundEX-funtion möchte ich eher nicht verwenden - ich hab mir mal das ergebnis eines solchen vergleichs angesehen: Laut Hilfe tut der Server folgendes: <br>
"...Smith und Smythe ergibt das gleiche SOUNDEX-Ergebnis, da die Vokale, der Buchstabe y, doppelt vorhandene Buchstaben und der Buchstabe h nicht einbezogen werden ..."<br>
doch im deutschen (besonders bei Vornamen !!!), sind nicht nur Konsonanten ausschlaggebend: So ist z.B. das SoundEX-Ergebnis von "Alois" und "Aloisia" ident - die Vokale am Ende des Strings sind die wichtigsten Buchstaben überhaupt, die sind ausschlaggebend für das Geschlecht... <br>

Zum Thema SQL-Statement: habe ich versucht - doch eine schlechtere Performance erzielt als mit Locate -> das kann aber auch damit zusammenhängen, dass ich einen localen SQL-Server zu Testzwecken "mißbrauche" - so wird es nicht besonders auschlaggebend sein, auf welche Weise in der großen Datenmenge navigiert und zurückgeliefert wird... veruche mit einem ordentlichen Server werden die gewünschten Ergebnisse liefern - wie auch immer ;-) <br>

Danke nochmals für die prompte und ausführliche Hilfe !!

[Andreas Kosch]

Hallo,

auf der Entwickler-Konferenz 2000 und den Entwickler-Tagen 2001 habe ich in meinem ADO-Sessions ein Beispielprojekt vorgestellt, dass die SELECT- und UPDATE-Performance von BDE, ODBC und ADO verglichen hat. Das Ergebnis war, das ADO bei "richtiger" Konfiguration mindestens genauso schnell ist wie der BDE, solange auf die gleiche Datenbank zugegriffen wird. Man darf allerdings die mengenorientierten SQL-Datenbanken nicht mit den datensatzorientierten Desktop-Datenbanken verwechseln, bei denen ein Index direkt auf den Datei-Offset verweist, so dass die BDE mit einem einfachen Seek das Ergebnis erhält. Bei einer SQL-Datenbank muss der Server eine Kopie der Daten über die Ergebnismenge der SELECT-Abfrage zusammenstellen.

Die besten Performance-Ergebnisse erhält man, wenn beim SQL Server die SELECT-Abfrage in eine Stored Procedure verpackt wird und diese im Fall von nur einem erwarteten Datensatz alle Ergebnisse als OUTPUT-Parameter zurückliefert. In dieser Stored Procedure wird die komplette Logik verpackt, die man ansonsten im Programm implementieren würde

[René von Arx]

Hallo Patrick
Ist das Anrede-ID Problem noch aktuell? Wenn ja, kann ich dir eine Tabelle mailen, die (fast) alle Vornamen mit dem Vermerk "männlich" oder "weiblich" beinhaltet. Kenne das Problem von früher her, als ich noch in einer Marketingfirma auch Adressveredelungen vorgenommen habe.
Wenn Du interesse an dem Teil hast, mail mich mal an ([email protected]).

Gruss
Ren&#233