bde schneller als firebird

[sancho1980]

nochmal ne andere frage:

bin dabei eine db-anwendung, die auf bde und paradox basiert, für firebird umzuschreiben

außerdem gibs dazu noch ne kleine software, die dann die datenbanken ins neue format konvertiert..jetzt hab ich mir mal testweise eine ziemlich große datenbank im alten format (mit zufallswerten) generieren lassen und sie ins neue format konvertiert und dann nach einträgen gesucht und dabei fällt auf, dass die suche unter der bde merklich schneller geht (ok, die datenbankstruktur ist im neuen format auch etwas komplexer aber die direkte suche nach indizierten feldern sollte das ja nicht beeinträchtigen, oder)

woran kann denn das liegen, is das normal?

achsoo: firebord als lokaler server

danke

martin

[Bernhard Geyer]

Wie ist dein Code für den Firebird-Zugriff (Beispiel)? Methoden die bei BDE bzw. lokalen DB's schnell sind sind u.U. bei SQL-Datenbanken nicht optimal.

[RavenIV]

hast Du mal versucht, mit anderen Komponenten (z.B. ZEOS) auf deinen FB zuzugreifen.
Die ibexpert-Sachen sind nicht allzu optimiert.

hast du firebird als Server laufen oder als embedded?
bei einem direkten Vergleich zu BDE solltest du embedded wählen.

[sancho1980]

net erschrecken: das ist eine terminologiedatenbank..sucht man nach einem bestimmten asterm, dann wird sicherheitshalber (falls der asterm nicht enthalten ist) auch der vorgänger und soviele nachfolger geholt, bis 20 datensätze insgesamt da sind..asterm ist indiziert, ebenso wie sämtliche fremdschlüssel...(hier suche nach asterm 'peter'):

SQL-Code:

select * from (
      select * from (
            select d.id, d.asterm,  d.asabk, d.asprgm, d.assem, d.zsterm, d.zsabk, d.zsprgm, d.zssem, d.datum, d.proj, d.rev, d.upddatum, d.asdef, d.zsdef, d.asaudio, d.asvideo, d.asabbildung, d.zsabbildung, d.zsaudio, d.zsvideo, asmain.asterm as asverw, zsmain.zsterm as zsverw, a.aut as aut, ua.aut as updaut, aslit.qcode as asqcode, zslit.qcode as zsqcode from dicentries d left join dicentries asmain on d.asverw = asmain.id left join dicentries zsmain on d.zsverw = zsmain.id left join aut a on d.aut = a.id left join aut ua on d.updaut = ua.id left join lit aslit on d.asqcode = aslit.id left join lit zslit on d.zsqcode = zslit.id where d.asterm < 'peter' order by asterm descending rows 1
               ) 
      union 
      select d.id, d.asterm,  d.asabk, d.asprgm, d.assem, d.zsterm, d.zsabk, d.zsprgm, d.zssem, d.datum, d.proj, d.rev, d.upddatum, d.asdef, d.zsdef, d.asaudio, d.asvideo, d.asabbildung, d.zsabbildung, d.zsaudio, d.zsvideo, asmain.asterm as asverw, zsmain.zsterm as zsverw, a.aut as aut, ua.aut as updaut, aslit.qcode as asqcode, zslit.qcode as zsqcode from dicentries d left join dicentries asmain on d.asverw = asmain.id left join dicentries zsmain on d.zsverw = zsmain.id left join aut a on d.aut = a.id left join aut ua on d.updaut = ua.id left join lit aslit on d.asqcode = aslit.id left join lit zslit on d.zsqcode = zslit.id where d.asterm = 'peter'
      union 
      select * from (
            select * from (
                  select d.id, d.asterm,  d.asabk, d.asprgm, d.assem, d.zsterm, d.zsabk, d.zsprgm, d.zssem, d.datum, d.proj, d.rev, d.upddatum, d.asdef, d.zsdef, d.asaudio, d.asvideo, d.asabbildung, d.zsabbildung, d.zsaudio, d.zsvideo, asmain.asterm as asverw, zsmain.zsterm as zsverw, a.aut as aut, ua.aut as updaut, aslit.qcode as asqcode, zslit.qcode as zsqcode from dicentries d left join dicentries asmain on d.asverw = asmain.id left join dicentries zsmain on d.zsverw = zsmain.id left join aut a on d.aut = a.id left join aut ua on d.updaut = ua.id left join lit aslit on d.asqcode = aslit.id left join lit zslit on d.zsqcode = zslit.id where d.asterm > 'peter' order by asterm ascending rows 20
                     )
               )
         ) order by asterm ascending rows 20

[RavenIV]

also wenn deine Abfrage so kompliziert ist, solltest Du vielleicht mal das DB-Design überdenken...

[sancho1980]

Zitat:

hast du firebird als Server laufen oder als embedded?

Du meinst, ob ich firebird als service oder als application laufen habe?
beim firebird service control steht "as a service"
wieso beeinträchtigt das die geschwindigkeit von suchen?

[Bernhard Geyer]

OK. Immerhin schon SQL und nicht mit Locate oder ähnlichen gearbeitet.

Wie sind denn die Zeiten?

[RavenIV]

Zitat:

Zitat von sancho1980

Zitat:

hast du firebird als Server laufen oder als embedded?

Du meinst, ob ich firebird als service oder als application laufen habe?
beim firebird service control steht "as a service"
wieso beeinträchtigt das die geschwindigkeit von suchen?

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.

[sancho1980]

also es gibt in tabelle dicentries so etwa 100000 einträge...bei der bdedauert die suchen nen augenaufschlag...unter firebird so 3 sekunden...also schon noch zu verkraften aber eben langsamer :-(

[RavenIV]

wie verwendest du denn die Suche in der BDE?
mit TTables, TDataste, TQuery oder wie?

lass doch mal Quellcode der Suche für BDE und der Suche für Firebird sehen...

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

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 :shock: 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 ? :shock: Ein Vergleich zwischen Äpfel und Birnen ist normal. :mrgreen: Hier handelt es sich aber eher um einen Vergleich zwischen Mücke und Elefant auf 3 Beinen.

[sancho1980]

ja wie gesagt, die datenbankstruktur ist etwas komplexer

aber kann ein insert/update-trigger als erklärung dafür herhalten, dass die suche von datensätzen langsam ist??

[Sharky]

HAi sancho1980,

kannst Du deinen "SQL-Code" aus Beitrag #18 bitte als Datei anhängen. Bei sovielen Zeilen scrollt man sich sonst die Flossen wund.
Danke.

[Hansa]

Zitat:

Zitat von sancho1980

ja wie gesagt, die datenbankstruktur ist etwas komplexer

aber kann ein insert/update-trigger als erklärung dafür herhalten, dass die suche von datensätzen langsam ist??

Das ist doch alles relativ. Was heißt schon "etwas komplexer" ? 8) Jo, in Deinem Flossen-SQL-Script scheint einiges falsch zu sein. Mir fiel jedenfalls wegen des vielen Scrollens dieser Trigger auf. Noch nie sowas gesehen. Dir ist aber klar, wann und wo der Trigger zuschlägt ? Fast immer ! Nur nicht bei Delete. Was sollen diese ganzen OR-Überprüfungen ? Jedes darin enthaltene Feld muß aus der Datenbank gelesen und mit einem anderen, was auch gelesen werden muß verglichen werden. Gut, weiterraten : was macht FB, sofern von den 50 Zeilen bereits 25 abgearbeitet sind und sich dann noch eines dieser Felder geändert hat ? Fängt der Trigger dann vielleicht wieder vorsichtshalber neu an ? Könnte sein. Schmeiß ihn doch raus und mache selber einen Test. Irgendwo stimmt da was nicht. Der Rest ist eben Spekulation.

Stop, nur beim "suchen" nach Datensätzen ? :shock: Dann ist es an der Stelle nicht der Trigger. Ich lasse das bereits Geschriebene aber vorsichtshalber trotzdem mal stehen. Wie wird denn "gesucht" ?

[mquadrat]

Eine solch Komplexe Query würde ich persönlich immer in eine Stored-Procedure packen. Wie sieht denn der Ausführungsplan der Query aus? Wieviele Datensätze werden denn gelesen?

[sancho1980]

Zitat:

Zitat von Sharky

HAi sancho1980,

kannst Du deinen "SQL-Code" aus Beitrag #18 bitte als Datei anhängen. Bei sovielen Zeilen scrollt man sich sonst die Flossen wund.
Danke.

jo

Zitat:

Zitat von Hansa

Was sollen diese ganzen OR-Überprüfungen?

Na ist doch klar; damit soll geprüft werden, ob der neue Datensatz gültig ist...wenn nicht, exception

Zitat:

Zitat von Hansa

Jedes darin enthaltene Feld muß aus der Datenbank gelesen und mit einem anderen, was auch gelesen werden muß verglichen werden.

Stimmt doch gar nicht.. Damit soll nur geprüft werden, dass wenn in dem neuen Datensatz "ASVERW" oder "ZSVERW" nicht null sind, bestimmte andere Felder null sind. Sonst ist der Record ungültig...

Zitat:

Zitat von Hansa

Wie wird denn "gesucht" ?

Wie gesagt, irgendwo weiter oben hab ich einen Beispielquery gepostet...

Zitat:

Zitat von mquadrat

Wieviele Datensätze werden denn gelesen?

Wie krieg ich das denn raus?

gruß

martin

[Lemmy]

Zitat:

Zitat von sancho1980

Zitat:

Zitat von Sharky

HAi sancho1980,

kannst Du deinen "SQL-Code" aus Beitrag #18 bitte als Datei anhängen. Bei sovielen Zeilen scrollt man sich sonst die Flossen wund.
Danke.

jo

dann solltest Du vielleicht auch das SQL-Script in dem Posting löschen oder hat sich jetzt durch das bloße anhängen etwas an der Scrollrate geändert? ;-)
Lemmy

[sancho1980]

ok, hab ich gemacht
aber man hätte es auch einfach zusammenfalten können...

[Hansa]

Uff, das Select in #4 ist gemeint ? :shock: Das ist ja alleine schon ziemlich Flossen-ungeeignet. :lol: :wall: Du wirst doch hoffentlich meine Frage mit dem Union dieser Tage nicht zum Anlass genommen haben, solch ein Ungetüm zu konstruieren ? Da ging es nämlich auch um ein 3faches per Union verknüpftes select mit Joins drin. Um die ursprüngliche Frage zu beantworten : es bestand bei mir keinerlei Bedarf einer Zeitmessung und die beteiligten Tabellen sind nicht gerade klein. Die Ursache ist wohl in Deinem Code zu suchen. An #4 komme ich jetzt nicht mehr dran, aber da war doch innerhalb der Unions gleich ein MEHRFACHES Join, oder ? :gruebel: Der Trick bei so was besteht darin, die Datemengen einzugrenzen und zwar mit "where". Der nächste besteht darin, das nicht ins Programm einzubauen, sondern zuerst extern zu testen. Sprich : in IBExpert. Dann sieht man auch die Anzahl der zurückgelieferten Datensätze. Dauert es auch da zu lange, dann besser dort die Logik überprüfen. Dann fehlt noch die Angabe der DB-Version. Firebird alleine genügt nicht mehr ! Ist es die 1.5, dann wäre es denkbar, daß die IBX querschießen. Das zu überprüfen wäre allerdings erst notwendig wenn das Ganze in IBExpert überhaupt sauber läuft.

Jetzt habe ich das obige als Entwurf gesichert und #4 nochmals durchgeguckt. Mann, mann. Da sind sage und schreibe 6 :!: Joins drin pro Select und das per Union. Jedes Select hat noch 2 Unter-Selects. Was soll das ? Im "Where" steht allerdings nur eine Bedingung. Wer soll denn jemals wieder verstehen, was da irgendwann gemacht wurde ? Du mußt das dringendst vereinfachen, dann sind die "Fehler" wahrscheinlich von alleine weg.

[sancho1980]

schau, der sinn der ganzen abfrage ist folgender:

ich muss in dem programm UNBEDINGT das dbgrid beibehalten..macht sich bei sql natürlich schwer; also war mein ausweg: immer genau 20 datensätze holen und wenn der benutzer bild-up oder -down drück, die vorherigen oder nächsten zwanzig holen...also wird das select-sql-statement immer wieder neu generiert

das sql-statement von dem du redest ist ein beispiel, wo der user grad nach dem record sucht, wo asterm = peter...mein ziel ist, dass der benutzer dan folgendes zurückbekommt im grid:

-zuerst den eintrag (falls vorhanden), der in der datenbank genau VOR 'peter' kommt
-dann (falls vorhanden) 'peter'
-dann sortiert alle weiteren, die nach 'peter' kommen

..und insgesamt zwanzig..also wie in nem richtigen grid, in dem sich 'alle`datensätze befinden...

jetzt verständlicher?

ps: ein einzelnder record wird ausgewählt mit:

SQL-Code:

select d.id, d.asterm,  d.asabk, d.asprgm, d.assem, d.zsterm, d.zsabk, d.zsprgm, d.zssem, d.datum, d.proj, d.rev, d.upddatum, d.asdef, d.zsdef, d.asaudio, d.asvideo, d.asabbildung, d.zsabbildung, d.zsaudio, d.zsvideo, asmain.asterm as asverw, zsmain.zsterm as zsverw, a.aut as aut, ua.aut as updaut, aslit.qcode as asqcode, zslit.qcode as zsqcode 
from dicentries d 
left join dicentries asmain on d.asverw = asmain.id 
left join dicentries zsmain on d.zsverw = zsmain.id 
left join aut a on d.aut = a.id 
left join aut ua on d.updaut = ua.id 
left join lit aslit on d.asqcode = aslit.id 
left join lit zslit on d.zsqcode = zslit.id 
where ...

[sancho1980]

ich dachte mir grad, ich versuch mich mal an ner sp, um zu sehen, ob damit irgendwas schneller wird...jetzt wollt ich testweise erstmal ne sp schreiben, die einen bigint entgegen nimmt, und mir alle records zurückgibt, deren id direkt auf diesen wert folgen, aber folgendes klappt irgendwie nicht:

SQL-Code:

SET TERM ^ ;

CREATE PROCEDURE NEW_PROCEDURE (
    X BIGINT)
RETURNS (
    ASTERM VARCHAR(80))
AS
DECLARE VARIABLE I BIGINT;
BEGIN
  for
    select dicentries.asterm
    from dicentries
    where dicentries.id > :x order by id rows 20
  into :asterm
  do
    suspend;
END^

SET TERM ; ^

woran liegt das?

danke,

martin

[mkinzler]

Ich weiß nicht was nicht geht, aber deine SP gibt ja nur ein Feld aus und nicht die Datensätze. Außerdem ist die Ausgabe auf 20 beschränkt.

[sancho1980]

genau

aber geht das bei dir etwa?

bei mir nicht...

[sancho1980]

ahhh...habs schon:

statt "rows 20" am ende "select first 20" am anfang

komisch, warum das in der sp auf einmal anders heißen muss... :?:

[mkinzler]

Ich habe mal dei datenbank angelegt und ein parr testdatensätze eingefügt. Ich habe auch einen Begin..end Block um das suspend gelegt. Bei mir funktioniert es.

SQL-Code:

SET TERM ^ ;

CREATE PROCEDURE NEW_PROCEDURE (
    X BIGINT)
RETURNS (
    ASTERM VARCHAR(80) CHARACTER SET WIN1252)
AS
begin
  for
    select dicentries.asterm
    from dicentries
    where dicentries.id > :x order by id rows 20
  into :asterm
  do
  begin
    suspend;
  end
end^

SET TERM ; ^

GRANT SELECT ON DICENTRIES TO PROCEDURE NEW_PROCEDURE;

GRANT EXECUTE ON PROCEDURE NEW_PROCEDURE TO SYSDBA;

[mkinzler]

Zitat:

statt "rows 20" am ende "select first 20" am anfang

die Anweisung rows ist neu und gibts erst ab FB2.0 vorher hies se First ...