bde schneller als firebird

[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 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 ? 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 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 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 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 von Hansa:

Wie wird denn "gesucht" ?

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

Zitat von mquadrat:

Wieviele Datensätze werden denn gelesen?

Wie krieg ich das denn raus?

gruß

martin

[Lemmy]

Zitat von sancho1980:

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 ? Das ist ja alleine schon ziemlich Flossen-ungeeignet. 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 ? 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