Performance-Prob mit Subselect

[mkinzler]

Musst du so höchstwahrscheinlich auch. in einer SP kann man DBMS-spezifische Dinge oft besser "verstecken"

[hoika]

Hallo,

ja schon, aber ne SP muss man auch pflegen,
das geht bei Quellcode halt einfacher.


Heiko

[alzaimar]

hoika,

sehe ich das richtig, das die drei Tabellen jeweils nur 1000, 4000 und 160 Einträge haben? Dann darf das doch nicht so lange dauern. Das müsste doch im 100-500ms Bereich liegen, auf jeden Fall unter 1 Sekunde. FB ist doch nicht wirklich so lahm, oder?

[TBx]

versuch mal folgendes:

SQL-Code:

Select Booking.booking_id, 
       Booking.project_id 
  From Booking 
    Join Project On Project.project_id=Booking.project_id 
    Join Pos On Pos.position_id=Booking.position_id 
  where not exists (
                    select except_projects.project_id 
                      from except_projects
                      where except_projects.project_id = booking.project_id 
                   )

Das Konstrukt exists bzw. not exists ist oft deutlich schneller als das in /not in Konstrukt, da eine kleinere Ergebnismenge erstellt werden muss.

Gruß

onlinekater

[hoika]

Hallo

> alzaimar
Die booking Tabelle enthält 300.000 Einträge.

> onlinekater
Die Not Exists Variante dauert hier länger als das Subselect (700 ms vs. 1100 ms),
der Zugriffs-Plan ist aber der gleiche.

Die Lösung mit dem left join klappt auch unter FB2.
Puh, doch keine SP benutzen
(der Code wird erweitert, ich brauche also viell. demnächst mehr Parameter,
da ist eine Query einfacher als ne SP).


Heiko

[alzaimar]

Zitat von onlinekater:

versuch mal folgendes:

So gut wie identisch mit der langsamen Lösung von hoika.

hoika: Ich habe mir angewöhnt, Standardqueries (die also zum Grundrepertoire der Anwendung gehören) in Views oder UDF zu packen. Man hat eine Abstraktionsschicht, die zudem noch eine Performancesteigerung bringt.

Du hast hier z.B. eine Sicht auf Positionen und Projekte, die nicht in der Except-Liste stehen. Das würde ich in eine View packen. WEnn FB hier schwächelt, dann eben in eine UDF oder SP. Nun sieht die Anwendung nur die View, SP oder UDF und erwartet einen bestimmten Output. Wie die Tabellen auf der DBMS-Seite konkret aussehen, ist egal und kann im Notfall auch nachträglich verändert werden.

[hoika]

Hallo,

schon klar, dass mit SP oder View, aber:

so muss ich nur das Programm warten,
bei einer SP (deren Parameter sich vielleicht auch noch ändern),
ist das sehr viel mehr Aufwand.

Bisher benutze ich SP's nur, wenn es unbedingt notwendig ist (Performance).


Heiko