Anzeige:
Ergebnis 1 bis 15 von 15

Thema: Wie Mehere SQL-Queries in eine verpacken?

  1. #1
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Wie Mehere SQL-Queries in eine verpacken?

    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?
    Geändert von Lin728 (20-08-2017 um 17:55 Uhr)

  2. #2
    Registrierter Benutzer
    Registriert seit
    22.06.1999
    Beiträge
    677
    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).

  3. #3
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Sorry...

    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.
    Geändert von Lin728 (20-08-2017 um 17:56 Uhr)

  4. #4
    Registrierter Benutzer
    Registriert seit
    22.06.1999
    Beiträge
    677
    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).

  5. #5
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Danke!

    Query Optimizer
    Geändert von Lin728 (20-08-2017 um 17:56 Uhr)

  6. #6
    Registrierter Benutzer
    Registriert seit
    27.12.2002
    Ort
    Matrix
    Beiträge
    194
    Zitat Zitat von ceisserer
    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

  7. #7
    Registrierter Benutzer
    Registriert seit
    27.12.2002
    Ort
    Matrix
    Beiträge
    194
    Zitat Zitat von 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).
    kommt auf die DB an. siehe inline-views bei oracle.


    -j

  8. #8
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Hmmm

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

    O.K., hier die Beispieltabelle:
    Code:
    MANDT	CHAR, CALTYP	CHAR , YEAR	SMALLINT, VIEW	CHAR(1), CALKEY	INTEGER, CALSYST  CHAR(1), FIRSTJD	INTEGER, CALDATA	CHAR(1098)
    Selectieren tu ich wie folgt:
    Code:
    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:
    Code:
    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?
    Geändert von Lin728 (20-08-2017 um 17:57 Uhr)

  9. #9
    Registrierter Benutzer
    Registriert seit
    22.06.1999
    Beiträge
    677
    Zitat Zitat von ceisserer
    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?

  10. #10
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    *g*

    Wie wär's denn mal mit 'nem INDEX?
    alle keys sind bereits indiziert
    Geändert von Lin728 (20-08-2017 um 17:57 Uhr)

  11. #11
    Registrierter Benutzer
    Registriert seit
    27.12.2002
    Ort
    Matrix
    Beiträge
    194
    Zitat Zitat von ceisserer
    *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

  12. #12
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    ???

    Ausführungsplan?
    Geändert von Lin728 (20-08-2017 um 17:58 Uhr)

  13. #13
    Registrierter Benutzer
    Registriert seit
    27.12.2002
    Ort
    Matrix
    Beiträge
    194
    Zitat Zitat von ceisserer
    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

  14. #14
    Registrierter Benutzer
    Registriert seit
    22.06.1999
    Beiträge
    677
    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.

  15. #15
    Registrierter Benutzer
    Registriert seit
    27.12.2002
    Ort
    Matrix
    Beiträge
    194
    Zitat Zitat von 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.
    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

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •