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

[michele_tedesco]

Hallo Zusammen

Bei der Evaluierung nach einer Alternative zu den heutigen DBase Tabellen, welche bei uns vor allem über TTable (BDE) zugegriffen werden, habe ich einen einfachen Test geschrieben um ca 17000 Records auszulesen.

Der Test hat die selbe DBF Datei in 4 verschiedene Arten ausgelesen:
- TTable
- TQuery
- TAdoTable (dbGo)
- TAdoQuery (dbGo)
(Programm im Anhang)

Ich habe die Events BeforeOpen und AfterOpen mit einem TimeStamp versehen und habe gemerkt, dass DBase-Tabellen über TTable x-Mal schneller gelesen werden können. 17 Millisekunden für das Anzeigen von 17000 Datensätze auf einer DBGrid.
Hier eine einfache Aufstellung:

Code:

ADO table beforeopen 07:58.106
ADO table afteropen 07:05.596
173071

ADO query beforeopen 07:22.947
ADO query afteropen 07:30.336
173071

query beforeopen 07:43.170
query afteropen 07:49.116
173071

table beforeopen 07:03.660
table afteropen 07:03.677
173071

Nun verstehe ich das BDE (und auch DBase??) depricated ist :-)

Daher bin ich überzeugt eine Alternative ist ein Muss.

Davon ausgegangen dass die DBase Tabellen über BDE dem Zweck gedient haben für eine Desktop-Applikation, welche auch offline (no internet, no cloud), Daten mehrheitlich in DBGrids darzustellen UND zu bearbeiten, frage ich mich was ist heute die gängigste Alternative, welche diesen Zweck erfüllt??

Was sind so eure Erfahrungen?

Ich hätte als nächstes einen Test mit der Firebird embedded Datenbank (über FireDAC) geschrieben, doch nun bin ich verunsichert ob da nicht zu viel "Performance" verloren geht :-(

Danke für eure Feedbacks!

[Lemmy]

Hi,

ich habe hier ein altes Projekt Delphi 5 + BDE auf Paradox Tabellen. Das habe ich auf XE2 umgestellt und da hier etwas Geschwindigkeit verloren geht auch einen Test bzgl. Auswertung bei Firebird gemacht.

Auswertung: Query über 2 Tabellen mit Daten (Rechnung + Rechnungsposition) über mehrere Jahre, genaue Anzahl bin ich gerade überfragt (jedenfalls mehr als 17.000 Einträge).
Query BDE: ca. 30 Sekunden
Query Firebird: ca. 3 Sekunden.

Wenn ich die Zeit für das anzeigen der Ergebnisse noch abziehe (ca. 1,5 Sekunden) dann sieht die Sache noch deutlicher aus 28,5 Sekunden:1,5 Sekunden. Und genau hier liegt der Vorteil von Firebird (und anderen "richtigen" DBMS): Die sind bzgl. Auswertungen verdammt schnell.

Allerdings kann ich dir auch sagen, dass Firebird mit großer Sicherheit bei deinem Test auch deutlich schlechter abschneiden wird als die BDE. Grund dafür ist einfach in der unterschiedlichen Art zu finden wie Firebird und lokale Filebasierte Datenbanken arbeiten.

[Union]

Irgendwie stimmt die Anzeige im O-Thread nicht mit dem überein, was Du in der Test-Unit programmiert hast (z.b. Recordcount-Zeit). Wenn Du nur die Datenzugriffe messen willst, dann solltest Du keine Seiteneffekte zulassen. Die Darstellung der Daten in einem Grid gehört definitiv nicht dazu. Und auch die Arbeitsweise sämtliche Daten (wobei das non-dterministisch ist) in einem Grid anzuzeigen und zu bearbeiten. Das ist die sog. Excel-Lepra.

[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

Delphi-Quellcode:

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"

:twisted::twisted:

Gruß
K-H

[Dejan Vu]

Zitat:

Zitat von Uwe Raabe (Beitrag 1307426)

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.