Moin,

ich habe eine Tabelle mit Indizes von Einzelkomponenten (z.B. 3000 Stück) vorliegen und muss zu diesen das Messdatum aus der Messdatentabelle auslesen. Im Moment mache ich das mit Einzelabfragen, was natürlich quälend langsam ist. Ich würde also gerne die Indizes übergeben.
Hier (#7) habe ich einen Ansatz gefunden, eine stored proc zur Laufzeit so zu verändern, dass man die aktuellen Daten übergeben kann.
Ist das ein gangbarer Weg, stored procs zur Laufzeit um zu bauen? Für mich gehören SP und Views zur Datenbankstruktur die ich nicht so gerne anfassen möchte.

Grüße, Messie

Hallo,

was verstehst du denn unter Indizes von Einzelkomponenten? Was ist denn bei dir ein Index bzw. welches Problem willst du lösen?

Hallo Thomas,

die Datenstruktur ist Auftrag -> Fertigungslos -> Komponente -> Subkomponente -> Messwertarray

Ich habe also jeden Messwert einzeln in der DB rumliegen. Er hat seinen eigenen Index, den der Subkomponente und den Timestamp. Es können aber mehrere Messpunkte an einer Subkomponente vorhanden sein (z.B. Nacharbeit oder Reklamation), daher muss ich die Timestamps untersuchen und sortieren. Im ersten Schritt habe ich für jeden in Frage kommenden Messpunkt eine eigene Query was natürlich lange dauert. Das möchte ich jetzt zusammenfassen, möglichst nach einer Methode "select * from DB where SUBCOMPONENT_ID is in ARRAY".


Grüße, Messie

Im Normalfall wird bei einer SQL-Abfrage nie ein Index mit angegeben.
Es ist Aufgabe der DB den richtigen Index für eine Abfrage aus zu wählen.
Es gibt allerdings die Möglichkeit bei einigen Dialekten den Index als "Hint" zu übergeben.
wie wäre es mit

markieren

Code:

select subkompo,messwert
from tabsubkompo join tabmesswert on (tabsubkompo.subkomponent_id=tabmesswert.subkomponent_id)

gruß
K-H

Das sehe ich wie p80286.
Ggf. je nach Suchkriterien ist das SQL Statement noch um die Zugriffe auf Auftrag -> Fertigungslos -> Komponente mit ensprechenden joins zu erweitern, sowie die Sortierung nach dem Timestamp, den Du erwähnt hast.

Generell: Es ist oft die Rede davon SQL durch den Einsatz von Stored Procedures zu beschleunigen. Die Idee ist häufig aber nicht sonderlich fruchtbar:
Wenn die SP nichts anderes tut, als Daten zu selektieren, indem ein Client SQL Statement in eine SP eingebaut wird, bringt das keinen spürenbaren Gewinn. Ausnahmen wären höchstens Effekte, die sich durch bessere Parameterierung/weniger Parsing des Statements ergeben. Auch das macht sich nur bemerkbar bei hoher Zugriffsfrequenz, also viele Nutzer des Statements oder häufiger Aufruf oder beides.

Eine SP lohnt sich eher bei komplexer Selection, mit Pufferung von Zwischenergebnissen, die nutzbringend weiterverwendet werden können uvam. ggF. auch wahlfreier (indizierter) Zugriff auf Teilmengen / Records (Stichwort window functions oder klassische Spreadsheet Funktionen). Ob das bei Deinem Problem wirklich der Fall sein sollte, wage ich zu bezweifeln.