bde schneller als firebird

[sancho1980]

ttables kommen da zum einsatz
quelltext hab ich grad nicht parat aber das war da über "gotonearest" (ich glaub so hieß die procedure) gemacht...

[Lemmy]

Hi,

verwende zum Zugriff auf Firebird (V1.5 setzt Du hoffentlich ein) nicht mehr unbedingt die IBX. Die tun zwar, aber....

Verwende entweder die UIB (haben allerdings ne schlechte Oberflächenanbindung) oder die MOD (noch nicht getestet) oder gleich ein kommerzielles Produkt wie die FIBPlus.

Wenn Du das Tabellendesign vernünftig gemacht hast, dann installier den FB-Server auf einem anderen Rechner, wenn das nicht geht schau zu dass die Datenbank (also das *.fdb File) auf einer anderen Festplatte auf deinem Rechner liegt, da solltest Du dann schon nen Geschwindigkeitsvorteil spüren, wobei ein eigener Server sicherlich Sinn machen würde.

Desweiteren solltest Du die TTable Komponente ganz schnell vergessen. Verwende für die Abfrage eine TIBDataset oder was vergleichbares (TIBQuery bitte auch nicht!).

Das war das wichtigste mal in Folge. Du wirst sicherlich noch viele Ecken finden, wo Deine Software langsamer ist als mit der BDE, aber das musst Du dann eben verbessern, sei es mit StoredProcedures, anderen Abfragen, Indizes,...

Grüße
Lemmy

[sancho1980]

Zitat:

der firebird-Server hat sicher andere Antwortzeiten als die embedded Version (nur DLL im Projekt eingebunden).
Die BDE ist am ehesten mit der embedded Version des Firebird vergleichbar.

wie muss ich mir den unterschied zwischen server und embedded vorstellen?

[RavenIV]

Zitat von sancho1980:

wie muss ich mir den unterschied zwischen server und embedded vorstellen?

geh doch auf die Homepage vom Firebird und lies das dort nach...

[Elvis]

Siehe hier, TTable ist die typische BDE-DAU-Klickibunti-Komponente.
Kein SQL, keine gefilterte Ergebnismenge, keine Performance, ...
Wenn die BDE bei TTable nicht schneller gewesen wäre wäre irgendwas kaputt.
Bei Paradox wirst du die ganze Tabelle direkt von der Datei in den Speicher laden. Das musst du da immer, deshalb sollte man annehmen, dass Borland dafür gesorgt hat, dass es halbwegs schnell geht.
Ein SELECT * ist in einem (poststeinzeitlichen) serverbasierten DBMS eher eine krasse Ausnahme. Solche System sind darauf optimiert Teilmengen zu finden und an den Client zu übertragen.
3 Sekunden für solch eine krasse Abfrage sprechen eindeutig für FB: Viele (auch teure) DBMS hätten das sicher länger gebraucht. (natürlich andere auch 10-mal weniger ).
Alleine das SELECT * & UNION zeugt deutlich von "wie gates ohne dass ich groß drüber nachden muss?"

[mkinzler]

Welche Indices hast du für df FB-Datenbank angelegt?

[sancho1980]

Zitat:

geh doch auf die Homepage vom Firebird und lies das dort nach...

das hatte ich schon aber da hab ich nur in diesem quick-start-guide die information gefunden:

Zitat:

The non-server Windows platforms – Windows 95, 98 and ME – do not support services. The installation
will start Firebird server as an application, protected by another application known as the Guardian.
If the server application should terminate abnormally for some reason, the Guardian will attempt
to restart it.

So wie ich das verstehe, haben die die Sache mit Application gemacht, damit Firebird auch auf älteren Windows-Versionen läuft. Aber schlauer werd ich daraus nicht: Sowohl ein Service als auch eine Anwendung sind doch einfach mal ein Prozess, nur dass ein Service eben ständig die Lauscher aufhält, falls einer von außen eine Anfrage macht - womit mir unklar wäre, was das mit Application soll und überhaupt, warum das schneller sein sollte (hab's mal getestet, ist tatsächlich ein µ schneller, kommt aber an die BDE-Variante immer noch nicht heran...

[sancho1980]

Zitat:

Wenn die BDE bei TTable nicht schneller gewesen wäre wäre irgendwas kaputt.

Nein, ich hab in der neuen Version natürlich TIBDataSet verwendet.

Zitat:

Alleine das SELECT * & UNION Shocked zeugt deutlich von "wie gates ohne dass ich groß drüber nachden muss?"

Das muss so sein. Der Anwender sucht beispielsweise nach einem Terminus in der Datenbank, und soll 20 zurück bekommen (ich soll bei dem Projekt unbedingt das DBGrid beibehalten). Zugegeben, es sind KOMPLETTE Datensätze, aber eben nur 20. Ich meine, was hier so viel Zeit in Anspruch nimmt, kann ja wohl nur die Suche sein und nicht nicht die Übertragung von 20 lausigen (wenn auch kompletten) Datensätzen, und eben darum geht's mir: warum FINDET die BDE das schneller?

[mschaefer]

Moin, moin

Ja, das kann schon sein. Spricht aber noch nicht gegen FB. Paradox ist für relativ einfache SQL-Strukturen eine flotte Lösung. Und da kein Umweg über TCP/IP genommen wird, sind auch keine Synchronisationszeiten in diesem Berich vorhanden. Zudem beherscht FB einen wesentlich größeren Befehlssatz und Funktionen wie die Transaktionskontrolle, was auch Zeit nimmt. Da ist bei Paradox einfach Ende. Arbeitet man mit komplexeren Where-Sttements in Queries, dann geht aber auch Paradox deutlich in die Knie, den das Ergebnis wird komplett auf Festplatte zwischengespeichert (Dateien im tmp-Verzeichnis) und das Dauert dann.

Paradox ist nicht schlecht. Probleme treten aber bei der gleichzeitigen Verwendung mehrere BDE-Anwendungen auf, da es hier schonmal zu Synchronisationsproblemen kommen kann. Hier liegt der Grund für den Entwicklungsstop der BDE.

FAZIT: Die Umstellung ist letzlich trotzdem der richtige Weg.


Grüße // Martin

[Hansa]

Das Fazit von Martin stimmt. Es nützt aber nichts, die DB falsch anzulegen. Ich sehe einen BIBU also Insert UND Update-Trigger mit sage und schreibe 50 Zeilen, die alle mit OR verknüpft sind. D.h.: alles muß abgearbeitet werden. Und das soll jetzt als Vergleich zur BDE dienen ? Wie ist so ein Trigger damit überhaupt hinzukriegen ? Ein Vergleich zwischen Äpfel und Birnen ist normal. Hier handelt es sich aber eher um einen Vergleich zwischen Mücke und Elefant auf 3 Beinen.