Delphi-PRAXiS
Seite 2 von 2     12   

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Performance-Prob mit Subselect (https://www.delphipraxis.net/107054-performance-prob-mit-subselect.html)

mkinzler 21. Jan 2008 17:26

Re: Performance-Prob mit Subselect
 
Musst du so höchstwahrscheinlich auch. in einer SP kann man DBMS-spezifische Dinge oft besser "verstecken"

hoika 21. Jan 2008 18:15

Re: Performance-Prob mit Subselect
 
Hallo,

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


Heiko

alzaimar 22. Jan 2008 06:54

Re: Performance-Prob mit Subselect
 
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? :shock:

TBx 22. Jan 2008 07:07

Re: Performance-Prob mit Subselect
 
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 22. Jan 2008 07:20

Re: Performance-Prob mit Subselect
 
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 22. Jan 2008 07:32

Re: Performance-Prob mit Subselect
 
Zitat:

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 22. Jan 2008 09:40

Re: Performance-Prob mit Subselect
 
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


Alle Zeitangaben in WEZ +1. Es ist jetzt 14:58 Uhr.
Seite 2 von 2     12   

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz