Laufzeit von Stored Procedure verkürzen

[Andidreas]

Zitat:

Zitat von Furtbichler (Beitrag 1185713)

Jo, is normal das das so langsam ist

Bedingt durch die Konvertierung?

fnSplit Teilt Werte wie z.B. "Test1;Test2;Test3" so wieder auf das es in einer Where Bedingung mit IN verwendet werden kann...

[Bummi]

Ich will ja nicht kritteln, aber die oft beklagte mangelhafte Lesbarkeit von SQL ist oft vermeidbar.

Warum arbeitest Du nicht mit mehreren Temptables für

[inventory].[dbo].[fnSplit](@Brand, ';')
[inventory].[dbo].[fnSplit](@Productline, ';')

die Zurechtgecasteten Auswahltabellen bereits eingeschränkt über o.g.

darüber dann die Kumulierungen laufen lassen ...

[DeddyH]

Zitat:

Zitat von Andidreas (Beitrag 1185715)

fnSplit Teilt Werte wie z.B. "Test1;Test2;Test3" so wieder auf das es in einer Where Bedingung mit IN verwendet werden kann...

Dann entspricht die DB nicht einmal der 1. NF? Wenn man da erst atomare Daten herstellen und konvertieren muss, ist es kein Wunder, wenn das "ein wenig" dauert.

[p80286]

Das ist ja wahrhaftig grauslich.
Da hat wohl jemand eine ASCII-Datei in eine Datenbanktabelle gekippt und das dann als Datenbank verkauft.

Ich würde auch soweit gehen, alle benötigten Daten in "richtige" Tabellen zu übertragen, und natürlich die Brands und Productlines in Temptables hinterlegen.

erschütterte Grüße
K-H

[Furtbichler]

Ich persönlich glaube nicht, das das Convert hier die Bremse ist, sondern die mehrfache Verwendung von Sub-Sub-Sub-selects.
Natürlich trägt CONVERT dazu bei, das das Ganze als legitimer Exekutionsgrund vor jedem Richter durchgeht.

Ich bin mal so frei:

Der, der das verzapft hat, ist ein Cretin. Ein ausgemachter Vollpfosten.

Außer Du warst das, andidreas.

Dann: Schäm dich und frag nächstes Mal.

[jobo]

Zitat:

Zitat von DeddyH (Beitrag 1185717)

Zitat:

Zitat von Andidreas (Beitrag 1185715)

fnSplit Teilt Werte wie z.B. "Test1;Test2;Test3" so wieder auf das es in einer Where Bedingung mit IN verwendet werden kann...

Dann entspricht die DB nicht einmal der 1. NF? Wenn man da erst atomare Daten herstellen und konvertieren muss, ist es kein Wunder, wenn das "ein wenig" dauert.

Ich glaub hier liegt ein Missverständnis vor. Vielleicht verwechsel ich das, aber vor einiger Zeit ging es hier genau um das Thema, "Mehrere Parameter an SP übergeben"

Was hier gesplittet wird, ist nicht ein DB Wert, sondern eine "Parameter Liste". Also nichts anderes als ein dynamischer Filter...

[DeddyH]

Achso, ich hatte das so verstanden, dass es sich um Daten eines einzelnen Feldes handelt. Mea culpa.

[jobo]

Zitat:

Zitat von Furtbichler (Beitrag 1185727)

Ich persönlich glaube nicht, das das Convert hier die Bremse ist, sondern die mehrfache Verwendung von Sub-Sub-Sub-selects.
Natürlich trägt CONVERT dazu bei, das das Ganze als legitimer Exekutionsgrund vor jedem Richter durchgeht.

Die Converts auf DB Seite dürften immerhin dafür sorgen, dass kein einziger Index greift sofern definiert.
Ich halte eher die Subselect für harmlos. Die n "Unions" bedeuten schon mal n +1 scans der gesamten Daten, die "Or" machen es nicht besser.

[Andidreas]

Zitat:

Zitat von Furtbichler (Beitrag 1185727)

Der, der das verzapft hat, ist ein Cretin. Ein ausgemachter Vollpfosten.

Japp ich bin der Cretin bzw. Vollpfosten der das verzapft hat :P

Zitat:

Zitat von jobo (Beitrag 1185730)

Was hier gesplittet wird, ist nicht ein DB Wert, sondern eine "Parameter Liste". Also nichts anderes als ein dynamischer Filter...

Richtig, das was in der fnSplit Funktion aufgeteilt wird sind Parameter die an die Stored Procedure übergeben werden...

Zitat:

Zitat von Furtbichler (Beitrag 1185727)

Dann: Schäm dich und frag nächstes Mal.

Das mach ich ja gerade :P

Zum besseren Verständnis mal noch die folgenden Infos...
Das es sich um eine reine ASCII Tabelle handelt und das dass nicht optimal ist weiß ich auch... Bei der kompletten Datenbank handelt es sich um eine Quick & Dirty Lösung bei der keiner daran dachte das sie länger verwendet wird bzw. soll. Naja mittlerweile wissen wir das wir damit noch länger arbeiten müssen und dürfen uns auch überlegen wie wirs besser machen...

Wie ich bereits erwähnt hab befinden sich in der Tabelle im Moment ca. 1 Mio. Datensätze... Monatlich wird ca. die gleiche Menge hinzukommen sodass nach einem Jahr Maximal 12 Mio. Datensätze sich in der Tabelle befinden...

So und nun zu meiner Aufgabe (und ich sags gleich, ich bin kein DB Spezialist!)...
Wir haben meherer Reports in Excel die auf diese Tabelle zugreifen und das soll performanter werden...
In einem Report werden für diverse Lagerkennzahlen Summen auf PLC (Product Life Cycle) Statusen errechnet... Da ich die Informationen nur Satz für Satz in der DB stehen hab ist mir nichts besseres eingefallen wie je PLC über Subselects die Werte zu ermitteln...
Hat hier jemand Verbesserungsvorschläge?

Die Stored Procedure mit den Unions war nur ein Test um den Source im VBA (Excel) übersichtlicher zu halten, also das ich dort nur eine Stored Procedure aufrufen muss anstatt sechs!

[Sir Rufo]

Ich gehe mal davon aus, dass die Tabelle für die Auswertung nur gelesen werden soll.
Datensätze werden einmal eingetragen und dann nicht mehr verändert.

Dann würde es sich für die Übergangszeit empfehlen auf diese Tabelle einen Insert-Trigger zu legen, der die Daten beim Einfügen in eine bessere Tabelle überführt. Das Einfügen von Daten wird sich minimal verändern, aber die Abfragen werden erheblich schneller (werden können).

Somit werden beide Abfragewege noch funktionieren und du kannst in Ruhe alle Zugriffe auf die neue Tabelle umstellen. Wenn das erledigt ist, dann den Import der Daten anfassen.