6
SQL-Abfrage beschleunigen durch View mit Variablen oder abspeichern der ABfrage
Hallo,
es gibt eine Tabelle mit knapp 120000 Datensätzen.
Darin gibt es wichtige Felder wie Kundenummer, UmsatzBelegposition,Belegnummer, UmsatzDatum.
Um jetzt den kumulierten Umsatz eines Kunden über einen Zeitraum bezogen auf Belegnummer abzufragen muss ich sowas schreiben wie:
Das ganze ist derzeit als AbfrageString in VBA in einer Excel-Mape hinterlegt. Da es viele verschiedene Abfragen gibt wird der Code umfangreich.
Mein Gedanke war nun diese Abfrage irgendwie im SQL-Server mit Variablen zu speichern, die dann aus dem VBA-Projekt von Excel kommen.
Außerdem erhoffe ich mir davon eine Geschwindigkeitssteigerung.
Ist sowas möglich?
es gibt eine Tabelle mit knapp 120000 Datensätzen.
Darin gibt es wichtige Felder wie Kundenummer, UmsatzBelegposition,Belegnummer, UmsatzDatum.
Um jetzt den kumulierten Umsatz eines Kunden über einen Zeitraum bezogen auf Belegnummer abzufragen muss ich sowas schreiben wie:
Select SUM( UmsatzBelegposition) AS Belegumsatz from Tabelle
where
Kundenummer ="KDNR"
and
UmsatzDatum >= "Datumuntergrenze" and UmsatzDatum <="Datumobergrenze"
group by Belegnummer ....Das ganze ist derzeit als AbfrageString in VBA in einer Excel-Mape hinterlegt. Da es viele verschiedene Abfragen gibt wird der Code umfangreich.
Mein Gedanke war nun diese Abfrage irgendwie im SQL-Server mit Variablen zu speichern, die dann aus dem VBA-Projekt von Excel kommen.
Außerdem erhoffe ich mir davon eine Geschwindigkeitssteigerung.
Ist sowas möglich?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 526770
Url: https://administrator.de/contentid/526770
Ausgedruckt am: 22.11.2024 um 07:11 Uhr
6 Kommentare
Neuester Kommentar
Hi,
Du kannst Dir in der Datenbank dafür Views erstellen. Damit kann man das dann "bequemer" abfragen. Sprich, der Quelltext unter VBA wird etwas kürzer, aber auch nur um die Längen der Abfragestrings. Aber schneller wird das dadurch auch nicht. Nicht, dass ich wüsste.
Wenn da nach der einfachen Abfrage noch weitere Aktionen mit diesen Daten erfolgen, Folgeabfragen entstehen usw., dann müsste man sehen, was man davon auch mit TSQL abfackeln könnte. Und sowas dann als gespeicherte Prozedure in der SQL-DB abgelegt, das könnte dann einen Gewschindigkeitsvorteil bringen.
E.
Du kannst Dir in der Datenbank dafür Views erstellen. Damit kann man das dann "bequemer" abfragen. Sprich, der Quelltext unter VBA wird etwas kürzer, aber auch nur um die Längen der Abfragestrings. Aber schneller wird das dadurch auch nicht. Nicht, dass ich wüsste.
Wenn da nach der einfachen Abfrage noch weitere Aktionen mit diesen Daten erfolgen, Folgeabfragen entstehen usw., dann müsste man sehen, was man davon auch mit TSQL abfackeln könnte. Und sowas dann als gespeicherte Prozedure in der SQL-DB abgelegt, das könnte dann einen Gewschindigkeitsvorteil bringen.
E.
Hallo,
für sowas gibt es BI Lösungen. Bei einem MS SQL Server ist das "Analysis Services" mit dabei.
https://docs.microsoft.com/de-de/analysis-services/analysis-services-ove ...
Da kannst du deine Daten im Vorfeld schon berechnen lassen und dann in Excel darstellen und auswerten.
Bis man sich auskennt ist ne spielerei, aber dann ist echt ne tolle sache wenn man sich auskennt.
Und die Auswertungen sind dann auch richtig schnell.
für sowas gibt es BI Lösungen. Bei einem MS SQL Server ist das "Analysis Services" mit dabei.
https://docs.microsoft.com/de-de/analysis-services/analysis-services-ove ...
Da kannst du deine Daten im Vorfeld schon berechnen lassen und dann in Excel darstellen und auswerten.
Bis man sich auskennt ist ne spielerei, aber dann ist echt ne tolle sache wenn man sich auskennt.
Und die Auswertungen sind dann auch richtig schnell.
Moin,
bezüglich der Geschwindigkeit:
Hast du Indexe eingerichtet?
Viele Grüße
bezüglich der Geschwindigkeit:
Hast du Indexe eingerichtet?
Viele Grüße
Hi
also grundsätzlich gibt es hier mehrere Hebel.
Ein einfacher View ist lediglich ein Alias für eine Abfrage. Entsprechend ändert sich an der Geschwindigkeit nix.
Ein Indexed View hingegen ist technisch eine neue Tabelle, die permanent aktualisiert wird, wenn sich die referenzierten Daten dahinter ändern.
Damit könnte man das ggf lösen. Kommt auf die Daten an. Damit könnte man also die Daten permanent schon aufbereitet vorhalten, was die schlussendliche Abfrage entsprechend verbessert.
Das wohl relevanteste ist aber: Sind die Tabellen mit den Umsätzen denn ordentlich Indexiert? Indexe bringen eigentlich immer am meisten Performance. und
also grundsätzlich gibt es hier mehrere Hebel.
Ein einfacher View ist lediglich ein Alias für eine Abfrage. Entsprechend ändert sich an der Geschwindigkeit nix.
Ein Indexed View hingegen ist technisch eine neue Tabelle, die permanent aktualisiert wird, wenn sich die referenzierten Daten dahinter ändern.
Damit könnte man das ggf lösen. Kommt auf die Daten an. Damit könnte man also die Daten permanent schon aufbereitet vorhalten, was die schlussendliche Abfrage entsprechend verbessert.
Das wohl relevanteste ist aber: Sind die Tabellen mit den Umsätzen denn ordentlich Indexiert? Indexe bringen eigentlich immer am meisten Performance. und
Mein Gedanke war nun diese Abfrage irgendwie im SQL-Server mit Variablen zu speichern, die dann aus dem VBA-Projekt von Excel kommen.
Das sollte sogar Standard sein. Parametrisierte Abfragen führen zu vorkompilierten Abfrageplänen im SQL, was grundsätzlich schon mal CPU Zeit spart.
1.) Indizes hinzufügen
2.) den Querystore anwerfen und gucken was da so teuer ist, man findet da auch Informationen über fehlende Indizes.
3.) Migration nach Columnstore Indizes, die sind für solche Art von Abfragen optimiert, diese sollten idealerweise auch noch komprimiert sein
4.) Tabelle nach "memory optimized" umstellen
2.) den Querystore anwerfen und gucken was da so teuer ist, man findet da auch Informationen über fehlende Indizes.
3.) Migration nach Columnstore Indizes, die sind für solche Art von Abfragen optimiert, diese sollten idealerweise auch noch komprimiert sein
4.) Tabelle nach "memory optimized" umstellen
Als Stichwörter würde ich jetzt noch materialized view und stored procedure in den Raum werfen die die Geschwindigkeit erhöhen können aber wie schon erwähnt ist der Index i.d.R. der Schlüssel zum Erfolg und bringt am meisten. Im konkreten Fall wäre ein Index auf Kundennummer und Umsatz Datum für deine Abfrage sinnvoll, aber natürlich verlangsamt jeder Index auch Schreibvorgänge auf der Tabelle, es gibt also eine Downside die sich auswirken kann.
