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.

[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.

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1307568)

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 ...

Ja. War vermurkster Code und Teile der SW haben AFAIK nicht Borland/Codegear/Emba gehört.
Aber mittlerweile hat man ja mit FireDAC eine passende neue Schnittstelle

Zitat:

Zitat von jobo (Beitrag 1307568)

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

Man hat viel zu lange diese noch lauffähig gehalten. Die paar die trotzdem gewechselt sind muss man mit den 10.000 € Kosten gegenrechnen jeweils die BDE noch (halbwegs) unter neuen Delphi und Windows-Versionen am laufen zu halten.

[jobo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1307576)

..Aber mittlerweile hat man ja mit FireDAC eine passende neue Schnittstelle

Ich dachte, das sind "nur" Zugriffskomponenten. Ist das eine eigene Engine? Beherrscht die heterogene Abfragen?

[mschaefer]

Moin zusammen,

Da wo ich die BDE am Laufen hatte, habe ich lange Firebird embedded genommen, inzwischen arbeite ich mit DB2 Express-C oder Oracle, letzteres wenn was in Verbindung mit APEX gebraucht wird.

PS: Ja, FireDAC regelt nur den Zugriff.

Grüße in die Runde

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1307613)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1307576)

..Aber mittlerweile hat man ja mit FireDAC eine passende neue Schnittstelle

Ich dachte, das sind "nur" Zugriffskomponenten. Ist das eine eigene Engine? Beherrscht die heterogene Abfragen?

Primär ist es eine Zugriffskomponente. Gegenüber der BDE hat es den "Nachteil" kein eigen Engine wie dBase mit zu bringen. Aber das sehe ich nicht als nachteil an da man damit ja fast jedes DBMS ansprechen kann. Wieso dann sowas (veraltetes) wie dBase mitschleppen.

Was meinst du genau mit heterogene Abfragen? Was genau brauchst du?

[jobo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1307619)

Was meinst du genau mit heterogene Abfragen? Was genau brauchst du?

Ich brauche nichts. Ich wollte lediglich auf dieses nette BDE "Feature" hinweisen. Heterogene Abfragen wie es bspw. auch die großen Server können. In einer Query mehrere Server unterschiedlicher Hersteller abzufragen.

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1307620)

Zitat:

Zitat von Bernhard Geyer (Beitrag 1307619)

Was meinst du genau mit heterogene Abfragen? Was genau brauchst du?

Ich brauche nichts. Ich wollte lediglich auf dieses nette BDE "Feature" hinweisen. Heterogene Abfragen wie es bspw. auch die großen Server können. In einer Query mehrere Server unterschiedlicher Hersteller abzufragen.

Die BDE kann hier vermutlich nur kleins DBs (und da primär Desktop-DBs) mehr schlecht als Recht mischen. Ich möchte sehen wie sie bei "richtigen" (also im GB-Bereich) sich bei Joins zwischen Datenbanktabellen auf unterschiedlichen Servern schlägt. Ich denke das sind (bei MS SQL-Server) SQL-Links und Co. viel brauchbarer.

[Uwe Raabe]

Zitat:

Zitat von jobo (Beitrag 1307613)

Beherrscht die heterogene Abfragen?

FireDAC erlaubt über LocalSQL auch den Zugriff auf DataSets unterschiedlicher Herkunft.

[jobo]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1307625)

Zitat:

Zitat von jobo (Beitrag 1307620)

..Heterogene Abfragen wie es bspw. auch die großen Server können. In einer Query mehrere Server unterschiedlicher Hersteller abzufragen.

Die BDE kann hier vermutlich nur kleins DBs (und da primär Desktop-DBs) mehr schlecht als Recht mischen. Ich möchte sehen wie sie bei "richtigen" (also im GB-Bereich) sich bei Joins zwischen Datenbanktabellen auf unterschiedlichen Servern schlägt. Ich denke das sind (bei MS SQL-Server) SQL-Links und Co. viel brauchbarer.

Ja, schon klar, spannend, wie solche Zugriffe dann optimiert werden, aber hey, das machen auch die Großen gerne mal falsch, selbst wenn sie nur auf sich selbst zugreifen.
Ist schon lange her, deswegen bin ich mir nicht wirklich sicher, aber ich hab im Kopf, dass man eigentlich alles abfragen konnte, was so im BDE Manager an Connections definiert war.

Zitat:

Zitat von Uwe Raabe (Beitrag 1307627)

Zitat:

Zitat von jobo (Beitrag 1307613)

Beherrscht die heterogene Abfragen?

FireDAC erlaubt über LocalSQL auch den Zugriff auf DataSets unterschiedlicher Herkunft.

Ach, cool!!

[Bernhard Geyer]

Zitat:

Zitat von jobo (Beitrag 1307633)

...aber hey, das machen auch die Großen gerne mal falsch, selbst wenn sie nur auf sich selbst zugreifen.

Du spricht von Oracle, stimmst? Haben hier öfter das Problem das Oracle seine Statistiken kaputt macht und dann eine Tabelle mit 10 Mio. Einträgen in den Statistiken ein NULL drin stehen hat. Und bei 0 Einträgen darf man ja einen Full-Table-Scan machen da ein Index ja viel zu langsam wäre :evil:

Zitat:

Zitat von Uwe Raabe (Beitrag 1307627)

Zitat:

Zitat von jobo (Beitrag 1307613)

Beherrscht die heterogene Abfragen?

FireDAC erlaubt über LocalSQL auch den Zugriff auf DataSets unterschiedlicher Herkunft.

Ach, cool!![/QUOTE]
Gibts auch Performaneergebnisse (ohne jetzt das selbst nachstellen zu müssen)?

[jobo]

Ich habe auch in dieser Größenordnung noch nie Probleme gehabt mit defekten Indices bei Oracle. Betrifft 10gR2 oder mittlerweile 12, unter 8 und 9 waren die Systeme mit denen ich Erfahrung hab noch nicht so groß. Der erste CBO unter Oracle 9 war allerdings mies.
Ich meinte eigentlich, dass sie (auch andere Systeme) nicht immer optimale Ausführungspläne bauen.

Ich denke von BDE oder Firedac sollte man da also keine Wunder erwarten. Wenn eine Query-Bedingung nicht brauchbar umgesetzt werden kann, wird halt die Tabelle runtergeladen (vermutlich).
Trotzdem wäre es ein günstiges System für heterogene Abfragen. Man muss halt schauen, dass man es nicht überfordert.