Lesegeschwindigkeit DBase (BDE) DBGrid (ALternative für die Zukunft?)

[p80286]

1) Wer braucht schon 17.000 Datensätze?
Wenn man nicht zum Stamme der Datenfresser gehört, kein Mensch. Und hier treten jetzt die "richtigen" DBMS auf, die z.B. auch SQL interpretieren können. Damit ist gezielte Datenextraktion nur noch ein Kinderspiel!
2) Ob Firebird oder MSSql-Express (heißt das noch so?) oder welche Embedded/lokale DB auch immer, das ist teilweise Geschmackssache teilweise eine Glaubenssache. Auf jeden Fall ist eine solche Lösung den DBase/Paradox-Dinosauriern vor zu ziehen, da sie durch ihre SQL-Schnittstelle einfach ausgetauscht werden können. Wenn Du es richtig aufgesetzt hast, dann wird die lokale Datenbank durch einen Server ersetzt, ob der in einem RZ steht oder unter Deinem Schreibtisch und es geht weiter.

(Ob ADO nun das richtige Tool ist um auf DBase-Dateien zuzugreifen, darüber kann man bestimmt auch streiten!)

Gruß
K-H

[mensch72]

wer wirklich alte und "schlecht" programmierte Applikationen(speziell Zugriffe und "Seek" per "RecNo") auf aktuellen Stand bringen will oder muss, der nehme irgendein ein MEMtable als DataSet.

kbmMemTable ist nicht ganz kostenlos und erst in der "ProVersion" richtig schnell(unter Win32), aber es erfüllt gut seinen Zweck bei solchen Anforderungen ein TTable als DataSet zu ersetzen. Da DBF Files im Prinzip nix weiter sind wie ein Header plus folgende Records mit fester Size, lässt sich auch mit wenig Aufwand ein native Live-Read-Adapter schreiben um auf ein DBF File auf Harddisk per kmbMMemTable direkt Native zuzugreifen. Wenn SQL Abfragen gebraucht werden, gibt es das auch noch als Zwischenschicht.

DataSet MemTables gibt es einige, wenn es um wirklich alte RecNo basierte Sachen geht, hat die KBM Variante aber ein paar Vorteile.

[mm1256]

Hallo,

wenn es schnell sein soll, und nativer Zugriff ohne Zwischenschicht, dann kann ich dir NexusDB empfehlen. Es ist meines Wissens die einzige Datenbank die komplett mit Delphi programmiert ist. Keine externen DLL's, zwischen Embedded Version oder externere Server-Version mit ein paar Codezeilen umzuschalten, und wirklich rattenschnell. Daten einlesen beispielsweise (Neuanlage, Import aus Textdatei) je nach Feldanzahl zwischen 40.000 und 100.000 Datensätze/Minute

[Dejan Vu]

Das etwas in Delphi geschrieben ist, ist ja nun kein Qualitätsmerkmal und 100k Datensätze pro Minute ist nicht rattenschnell. 100k DS pro Sekunde wären schnell.

Wie schon erwähnt, ist der Ansatz ziemlicher Murks, 17k Datensätze anzeigen zu lassen. Obwohl, wenn man genau weiß, das es nie mehr als die paar DS werden, kann man das schon machen: Dann muss man sich keine großartigen Gedanken um Pagination machen und kann mit einfachen Mitteln ein kleines Frickeltool hinbasteln.

Generell sollte man aber keine großen Mengen an Daten transportieren, denn man ist i.A. nicht alleine im Netz. Muss man aber immer selbst entscheiden.

Und die einzig richtige Alternative zu DBase heißt: Irgend ein ordentliches RDBMS, also FB, SQL-Server Express usw. Die kosten nichts und sind trotzdem 'fett', wie man so schön sagt.

xxMemData ist eine sehr gute Wahl, wenn die Daten lokal und exklusiv gehalten werden, d.h. kein Mehrbenutzerzugriff benötigt wird.

[Uwe Raabe]

Auch mit der BDE werden keine 17k Records geladen und im Grid angezeigt, sondern nur immer soviele wie sichtbar sind. Wegen der direkten Adressierung über die RecNo und die Tatsache, daß die Tabelle physikalsich als Datei im Zugriff ist, kann die BDE da halt sehr schnell positionieren.

Die Rückgabemenge einer SQL-Abfrage muss aber erstmal erzeugt werden, um darin zu navigieren. Deswegen ist bei einer SQL-Query mit 17k Records das Open; Last; deutlich langsamer als bei der BDE, für die das am Ende lediglich ein FileSeek ist. Auch das seitenweise durchblättern der 17k Datensätze (aber wer will das schon) ist mit der SQL-Query nicht wesentlich langsamer, wenn man nicht beim Open schon alle Datensätze abruft, sondern nur soviele, wie ins Grid passen. Bei FireDAC z.B. würde man den FetchOptions.Mode auf fmOnDemand stellen (bzw. belassen).

Die SQL-Abfrage hat aber genau dort einen entscheidenden Vorteil, wo ich die Datenmenge vorab schon einschränken kann und dem User nur das präsentiere, was er wirklich braucht. Das erfordert an manchen Stellen schon ein bisschen mehr Überlegung als nur ein Grid auf das Form zu schubsen und mit einer Tabelle zu verbinden.

Jemand hat das mal mit der Telefonauskunft verglichen (ja, ist schon 'ne Weile her): SQL ist "Geben Sie mir bitte die Nummer von Heinz Müller, Heusengasse 14 in Köln". BDE ist: "Lesen Sie mir bitte das Telefonbuch von Köln vor und wenn ich Stop sage, geben Sie mir die Nummer".

[p80286]

SQL ist "Bitte geben Sie mir die Telefonnummer, die Etage und die Farbe der Wohnungstür von allen Kölnern deren Name "lle" enthält
deren Hausnummer 14 ist
und deren bevorzugter Sportverein Fortuna Düsseldorf ist
sortiert nach der 3.Stelle der Telefonnummer"



Gruß
K-H

[Dejan Vu]

Zitat von Uwe Raabe:

Auch mit der BDE werden keine 17k Records geladen und im Grid angezeigt, sondern nur immer soviele wie sichtbar sind. Wegen der direkten Adressierung über die RecNo ...

Wie macht die BDE das bloß, wenn ich damit einen SQL-Server anspreche? Wahnsinn.

[jobo]

Schätze, die hat ein SQL Statement an den Server geschickt, oder?
Ich fand die BDE eigentlich immer ganz gut. Das schlimmste war der vergurkte Lockmechanismus.
Aber man konnte damit heterogene Datenbankzugriffe machen.
Frag mich immer, warum sie beerdigt wurde, statt sie aufzubohren. Waren da soviel Leichen im Keller? Multibytefähigkeit wäre vlt eine davon, Lizenzprobleme, Patente vielleicht ...

Wenn ich heute noch solche Anfragen zur BDE Ablösung sehe, frage ich mich, wieviele Kunden Borland damit wohl hopps gegangen sind.