Array in SQL

[Jasocul]

@Aviator:
Kein Problem. Manchmal sind es die einfachen Dinge, die zur Lösung führen, weil man zu kompliziert denkt.

@MichaelT:
Alle Daten werden sequentiell verarbeitet (alles ohne order by, joins, ...). Die Aktualisierungen natürlich nicht, aber die sind im Test auch nicht aktiviert. Die Statistiken können somit keine Rolle spielen.

Aber der Hinweis auf Static hat mich ein bisschen weiter gebracht. Allerdings war es read_only, was mir 2 Minuten Verbesserung gebracht hat. Danke für den Anstoß. Static bringt in diesem Zusammenhang nur ein paar Sekunden.

Ich bewege mich also jetzt zwischen 7 und 8 Minuten, was schon deutlich besser ist, aber immer noch relativ lange ist. Weitere Tipps sind willkommen.

[Papaschlumpf73]

Bei so wenigen Datensätzen in den Nachschlagetabellen könnte eine Tabellenvariable deutlich schneller sein als eine temporäre Tabelle.

DECLARE @MyTableVar table(ID int, ...)

[Jasocul]

Zitat von Papaschlumpf73:

Bei so wenigen Datensätzen in den Nachschlagetabellen könnte eine Tabellenvariable deutlich schneller sein als eine temporäre Tabelle.

Hatte ich das noch nicht geschrieben? Sorry.
Es gibt dabei keinen zeitlichen Unterschied. Ich habe den Eindruck, dass der Server intern eine temporäre Tabelle dafür anlegt. Ich muss ja auch bei einer Tabellen-Variablen einen Cursor verwenden. Oder gibt es dann andere Möglichkeiten, die ich übersehen habe und die schneller ist?

[MichaelT]

Gerne. Ich habe das nur geschwind aus der Doku nachgeschlagen.

READ ONLY glaube ich sofort. 2 Minuten war nicht der Big Win

Gut. Soweit ich die CURSOR Thematik am SQL Server have verstanden.

Ich gehe jetzt mal davon aus, dass du den CURSOR nicht so einfach kannst ersetzen...

Damit verbleiben jetzt mal 2 Varianten
a) Sortieren
a1) In der Hoffnung, dass der SQL Server einen Index nimmt oder so
b) Sequentiell durchklappern und die wahrscheinlicheren Kombinationen vorne anstellen.
b1) Möglw. hilft das vermeiden von der Neuerstellung von Execution Plans beim Absetzen von Queries

Möglw. kannst du einen Clustered Index verwenden, je nachdem kann das etwas bringen.

Wenn das nichts hilft dann temporary table mit Schlüssel. Die Frage bleibt ob du überhaupt einen Schlüssel hast usw..

Mir kommt aber vor, dass aus irgendeinem Grund bei der Navigation jedes mal ein Statement wird abgesetzt.

Selbst im ABAP bei einer unsortierten Tabelle (in memory buffer ohne key) verliert man zwar Zeit aber bei weitem nicht in der Dimension. Das einzige mal bei dem mir Laufzeitunterschiede in der Dimension unterkam (mal von SQL abgesehen) war als der ABAP Prozesser aufgrund von Cluster


Gruß

Zitat von Jasocul:

@Aviator:
Kein Problem. Manchmal sind es die einfachen Dinge, die zur Lösung führen, weil man zu kompliziert denkt.

@MichaelT:
Alle Daten werden sequentiell verarbeitet (alles ohne order by, joins, ...). Die Aktualisierungen natürlich nicht, aber die sind im Test auch nicht aktiviert. Die Statistiken können somit keine Rolle spielen.

Aber der Hinweis auf Static hat mich ein bisschen weiter gebracht. Allerdings war es read_only, was mir 2 Minuten Verbesserung gebracht hat. Danke für den Anstoß. Static bringt in diesem Zusammenhang nur ein paar Sekunden.

Ich bewege mich also jetzt zwischen 7 und 8 Minuten, was schon deutlich besser ist, aber immer noch relativ lange ist. Weitere Tipps sind willkommen.

[jobo]

Ich habe nicht alle Antworten gescannt. Würde sowas helfen?

SQL-Code:

DECLARE @ListOfWord TABLE(aWord VARCHAR(100), aCategoryID VARCHAR(100), aID IDENTITY(1,1)); -- oder so ähnlich
INSERT INTO @ListOfWord 
SELECT tword, tcat from WordTable;

SELECT * FROM @ListOfWord;
GO

Hab kein MSSQL im Einsatz, also ist es nur Theorie. Macht nur Sinn, wenn die Werte auf diesem Weg gecached werden, statt immer erneut aus der Originaltabelle gelesen zu werden.

Ansonsten wäre es auch nicht verkehrt, das Statement selbst mal hier zu zeigen oder die Hilfsoperationen.

[Jasocul]

@jobo:
Im Prinzip mache ich es bereits genau so. Das hat aber keinen erkennbaren Unterschied gemacht.

@hanvas:
Wirkt ein wenig, wie mit Kanonen auf Spatzen, wobei es prinzipiell besser sein würde, näher an der Quelle der Daten zu arbeiten.

Ich hatte gestern beim Einschlafen noch eine Idee, die ich heute ausprobieren werde.
Ansatz: Ich bastel mir einen String, der einen definiertes Trennzeichen zwischen den Datensätzen und einen anderen zwischen den Wortpaaren hat. Alternativ nehme ich zwei Strings. Über Charindex durchlaufe ich dann die Listen anstatt den Cursor zu durchlaufen. Bin gespannt, wie effektiv das ist.

EDIT ERGEBNIS:
Die dadurch notwendigen String-Operationen kosten soviel Performance, dass es kaum einen Vorteil bringt.

[Jasocul]

Nach eingehender Untersuchung meiner String-Operationen, konnte ich noch doch noch einiges rauskitzeln.
Von der ursprünglichen Laufzeit von ca. 10 Minuten, bin ich jetzt runter auf unter 6,5 Minuten und ich habe noch einige Stellen gesehen, die potential haben.

Der Trick:
Es geht ja um Wort- und Buchstaben-Ersetzung mit verschiedenen Nebenbedingungen. Die Bedingungen lasse ich aber jetzt mal weg. Die Austauschtabellen haben insgesamt keine 100 Datensätze, sind also ziemlich kein.

Ich habe mir zwei varchar-Variablen und zwei Integer-Variablen deklariert.
Über einen Cursor fülle ich varchars mit einem Trennzeichen zwischen den Feldern. Einer enthält die Suchbegriffe und der andere die Ersetzungsbegriffe.
Die Integer halten in einer Schleife fest, bei welchem "Index" ich mich befinde. Bestimmt wird das über den Charindex des Trennzeichens.

Ich bin mit der Lösung erstmal zufrieden. Jetzt muss ich nur noch schauen, wo ich die String-Operationen optimieren kann.

[Sir Rufo]

Zeig doch mal die Definition von dem Cursor.

Es gibt da die ein oder andere Möglichkeit so einen Cursor schneller zu machen.
https://msdn.microsoft.com/de-de/library/ms180169.aspx

[Jasocul]

Code:

declare crsParam1 cursor scroll READ_ONLY for
select Begriff, Ersatz from @ParamTable1

scroll ist leider zwingend.
Ich habe auch mit local und static getestet. Die haben aber keinen spürbaren Effekt.

[MichaelT]

Hast du einen Index auf der 'großen' Tabelle der laufend upgedated wird?

Ok, jobo war flinker.

Wobei sich sofort die Frage stellt. Wieviele Datensätze Altbestand werden angegriffen bei der Verarbeitung usw...

Dann mal einen Test mit der doppelten bis 4 fachen Datenmenge machen.