Wie Firebird richtig abfragen weil drucken extrem langsam..

[mkinzler]

Ein select * und fehlende Einschränkungen( where ) führen oft zu Performanceproblemen

Besonders whwn man dies dann rekursiv macht

[jobo]

Ist der "Grid Select Code" als Beispiel zu verstehen oder verwendest Du das so?

ich bin kein FB Kenner, aber ich würde
- OR in der Whereclause eher vermeiden, alternativ IN ()/ Mengenoperator nehmen.
- Parameter verwenden, statt verkettete Statements (weiß nicht, wie FB das macht, aber Oracle würde alle diese Abfragen (bis 4 Unterebene immer wieder parsen!)

Und etwas spezifischeres als alle Orders zu selektieren, könnte auch hilfreich sein.

[mkinzler]

Jedes DBMS würde neu Parsen, wenn es einen neuen Abfragestring bekommt.

[erich.wanker]

@jobo
Ist der Beispiels-Code von www.tek-tips.com
Or / IN ... gibt es da Performance-Unterschiede ?
Select * from .. ist bei mir natürlich: Select Feldname, Feldname, Feldname..


@Allgemein

Wie im ersten Posting beschrieben gibt es ja verschiedene "Ebenen" der Tabellen:
(..ups ich sehe grade, dass ich überall "Datenbank" anstelle "Tabelle" geschrieben hab)

• Haupttable
• Subtable 1
• Subtable 2
• ...

Wenn in der Haupttabelle sagen wir mal 30 Datensätze markiert werden, wird die Subtable 1 30x per haupttable.afterscroll mit "Select * from Subtable 1 where ID = haupttable.ID .." gefiltert..

Wenn in jeder Teilmenge von Subtable 1 - 10 Records überbleiben, wird Subtable2 300x via SQL Statement gefiltert..

Gibts da irgendwie einen Trick, das zu umgehen ?

Subtable2 nur einmal filtern und mit locate oder bookmarks die Daten der Teilmenge zum drucken "markiere" ?


Vielen Dank
Erich

[jobo]

OR / IN
Ich kann das nur erfahrungsgemäß beantworten, da ich nicht mit FB arbeite. OR macht gerne mal mehrere Scans (also grob für jeden OR Fall)
IN hat natürlich eine andere Funktionalität, die es aber dem Analyzer erlaubt, etwas zielgerichteter zu arbeiten. IN würde aber in Deinem Fall passen.

Letztlich müsstest Du Dir die "Mühe" machen, Ausführungspläne der beiden Varianten zu vergleichen. Ist natürlich statisch dann, die Unterschiede evtl. marginal, aber die Menge machts dann halt.

Ansonsten:
Bei Queries oder auch gerade bei Report Komponenten wird gerne mal ungewollt die Datenmenge ohne Filter geöffnet (wenn mit Filterproperties gearbeitet wird, z.B. sofort bei "Open"). Und bei harmlosen Reports mit einer Untermenge fällt das dann u.U. erst im Produktivbetrieb auf oder wenn dutzende User diese Reports aufrufen.
In der Richtung würde ich mal den Code, das Verhalten untersuchen.

Locate & Co
Denkbar wäre es, alle 4 Mengen vollständig zu öffnen, mittels Query und gleich richtig sortiert. Dann könnte man Locate oder sogar nur mit Next arbeiten. Könnte schnell sein, würde ich aber als Notlösung sehen.

Wenn Du Dir sicher bist, dass Indizierung und alles andere stimmt, kannst Du auch probehalber 4 Datenquellen mit Datasource und Grids untereinander hängen und mal "sehen", wo die Performance bleibt.
Wenn das flott geht, dann Report Kompos oder deren Verdrahtung genauer anschauen.

Ich würde mit den Ausführungsplänen anfangen. Das ist die Basis und häufig denkt man nicht so, wie der QueryAnalyzer der DB "denkt".

[mschaefer]

Dies ist kein Datenbankproblem. Das Thema war eher scrollen im Grid. Wenn man bei jedem nicht relevanten Datensatz die abhängige Abfrage anfordert, kann ein nicht in Memory DBMS nicht hinterherkommen. Es muss eigentlich nur der Datensatz angefordert werden, bei dem der Nutzer eine Pause im Scrolling einlegt.

Vorschlag: Im OnScroll-Event einen Tiner reseten und die Unterabfrage und Timer disabled im Timer-Event.

Grüße in die Runde

[hoika]

Hallo,

Zitat:

Dabei wird bei "AfterScroll" der Hauptdatenbank die SubDatenbank 1 via "Select from.." gefiltert..
Die SubDatenbank 2 wird bei "AfterScroll SubDatenbank 1" gefiltert
Die SubDatenbank 3 wird bei "AfterScroll SubDatenbank 2" gefiltert
Die SubDatenbank 4 wird bei "AfterScroll SubDatenbank 3" gefiltert

Das wären bei mir dann 4 separate Queries,
mindestens die letzten 3 sind prepared,
weil ja bis auf einen variablen Tei (=Parameter) immer das gleiche abgefragt wird.

Woher weist du eigentlich, dass deine Queries ordentlich "indiziert" sind ?


Heiko