Wie Mehere SQL-Queries in eine verpacken?

[Lin728]

Hallo!

Ich schreibe gerade eine Anwendung, welche Daten aus der Datenbank relativ schnell benötig und noch dazu mehrere Abfragen machen muss.
Man kann sich das ganze als "Excel"-Tabelle vorstellen, in der auf der Zeitachse gescrollt werden kann.
Derzeit mache ich für jeden User (vertikal in der Tabelle) eine Query, was sich schnell auf 20Queries anhäuft.

Ich habe mir gedacht man könnte die Queries irgendwie zusammenfassen, vieleicht eine lange verkettung von where blabla=bl AND blup=p OR hha=b AND ... OR AND OR...., oder gibt eine andere Möglichkeit die Abfragen irgendwie zu beschleunigen? Würde das was bringen?

[Christoph]

Mehrere Queries zusammenpacken geht mit reinem SQL nicht, sondern nur mit Stored Procedures (siehe Dir z.B. mal die PostgreSQL-Doku zu dem Thema an).

Wenn die Ergebnistabellen identische Spalten haben geht allerdings UNION ALL (sollte in jedem SQL-Buch beschrieben sein).

[Lin728]

Sorry , ich glaube meine Frage ist ein wenig falsch rübergekommen.

Ich habe eine Tabelle und möchte mehere reihen effizient auf einmal (mit einer query) selectieren.
Ich wollte fragen ob es eine gute idee ist, sämtliche keys über "OR" zu verknüpfen also z.B. ("Select * from Tabelle where key1=1 AND key2=2 OR key1=2 AND key3=2 OR key1 ..AND...OR...), oder ob man lieber viele kleinere Queries machen sollte.

[Christoph]

Eine komplexe Query ist immer besser als viele kleine, weil weiniger Netzwerk-Overhead und der Query-Optimizer optimieren kann. Ob Du das mit OR-Verknüpfungen oder UNION machst, sollte in Deinem Fall eigentlich egal sein (ich würde aber spaßeshalber troztzdem mal beide Varianten ausprobieren).

[Lin728]

Query Optimizer :)

[Jasper]

Ich habe mir gedacht man könnte die Queries irgendwie zusammenfassen, vieleicht eine lange verkettung von where blabla=bl AND blup=p OR hha=b AND ... OR AND OR...., oder gibt eine andere Möglichkeit die Abfragen irgendwie zu beschleunigen? Würde das was bringen?


gib eine demotabelle und beschreibe, was die query liefern soll.


-j

[Jasper]

Mehrere Queries zusammenpacken geht mit reinem SQL nicht, sondern nur mit Stored Procedures (siehe Dir z.B. mal die PostgreSQL-Doku zu dem Thema an).


kommt auf die DB an. siehe inline-views bei oracle.


-j

[Lin728]

Erst einmal danke vielmals für die vielen Tipps und Antworten, ihr habt mir bis jetzt echt viel weitergeholfen.

O.K., hier die Beispieltabelle:


MANDT CHAR, CALTYP CHAR , YEAR SMALLINT, VIEW CHAR(1), CALKEY INTEGER, CALSYST CHAR(1), FIRSTJD INTEGER, CALDATA CHAR(1098)

Selectieren tu ich wie folgt:


WHERE mandt=??? AND caltyp=??? AND calkey=?? AND year=???


Das ganze muss ich für ca. 30-50 Elemente pro Server-Anfrage machen und es sollte nicht länger als 50-100ms dauern.
Da aber die Tabelle durch CALDATA schon relativ groß ist und eher viele Einträge zu erwarten sind ca. 100.000, sinkt die Performance bodenlos in den Keller :-(

Ich hab mir gedacht ich könnte das also so machen:


Select * from calendar where (bedingungen für element1) OR (bd.f. element2) OR ..... OR (bed.f. element 40)


Könnte das klappen? Denke mir dass eine derartige Anfrage schon länger dauert wie eine einfache aber trotzdem kürzer als lauter einzelne, oder?

[Christoph]

Da aber die Tabelle durch CALDATA schon relativ groß ist und eher viele Einträge zu erwarten sind ca. 100.000, sinkt die Performance bodenlos in den Keller :-(

Wie wär's denn mal mit 'nem INDEX?

[Lin728]

Wie wär's denn mal mit 'nem INDEX?


alle keys sind bereits indiziert

[Jasper]

*g*, nöö im ernst, alle Keys sind bereits indiziert.


wobei es durchaus sein kann, dass indizes in diesem fall negativ sind. poste doch mal den ausführungsplan solch einer query. die tabelle ist doch komplett analysiert, oder?


-j

[Lin728]

Ausführungsplan?

[Jasper]

Ausführungsplan? Tabelle analysieren?
Hmm -> Bahnhof *g*

Sorry, mir sagen die Begriffe nicht wirklich was, bin nicht so der Datenbank-Spezi...


wenn du die tabelle nicht analysiert hast, wird der RBO (rule based optimizer) verwendet. dieser optimizer verwendet IMMER indizes, was oftmals zu schlechter performance führt.

ich vermute du hast keine erfahrung mit querytuning/tracing, deshalb mal das ganze schritt für schritt (erst den trace, analysieren kommt später). angenoimmen, der user unter dem die queries abgesetzt werden ist USER1. dann mach mal folgendes als sysdba in sqlplus:

@?/sqlplus/admin/plustrce.sql;
grant plustrace to USER1;

weiter als USER1:
@?/rdbms/admin/utlxplan.sql;

set autotrace trace exp stat;
<hier jetzt das statement absetzen und ganzen output (statement+trace) posten>


-j

[Christoph]

Ein weiteres Problem könnte sein, dass Du Abfragen mit LIKE oder UPPER machst, so dass Indizes nicht genutzt werden können. PostgreSQL bietet für diesen Fall "funktionale Indizes" an, bestimmt gibt es bei Oracle irgendwas vergleichbares.

[Jasper]

Ein weiteres Problem könnte sein, dass Du Abfragen mit LIKE oder UPPER machst, so dass Indizes nicht genutzt werden können. PostgreSQL bietet für diesen Fall "funktionale Indizes" an, bestimmt gibt es bei Oracle irgendwas vergleichbares.

gibt es. heisst sogar genauso. aber ohne ausführungsplan wird optimieren zum kaffeesatzlesen. und vor dem wilden erstellen von indizes sollte man sich hüten, oftmals kommt dabei der entgegengesetzte effekt heraus.


-j