Konzeptfrage zu SQL: in Schleife(?) auf Bedingung prüfen

[juergen]

Ich habe das ganze nun direkt mit 3000(!) 8-stelligen Rec-Id's in einem SQL-Statement über die IN Bedingung ausgeführt. Das funktioniert! Dauert ca. 1,5 Sekunden. Danach habe ich es wiederholt mit 6 stelligen Rec-Id's, da sah ich auch das Ergebnis (meine Test-Tabelle hat ja nur 600 000 Datensätze).

Was meint ihr, sollte ich das trotzdem "aufbröseln" in kleine Häppchen, also in mehrere SQL-Statements?
Ich finde in der Hilfe keine Limitierungen.

[Furtbichler]

Zitat von juergen:

Was meint ihr, sollte ich das trotzdem "aufbröseln" in kleine Häppchen, also in mehrere SQL-Statements?
Ich finde in der Hilfe keine Limitierungen.

Ja, mach das. Wenn bei dir die 3000 funktionieren, bitte sehr. Und die 1,5s könnte man zwar theoretisch unterbinden, aber wozu. Ich kann mir vorstellen, das die BDU-Lösung bei den paar IDs, mit denen du derzeit in der Textdatei hantierst, auch nicht schneller ist.

Als Übung wäre es jedoch eine gute Sache. Es ist immer praktisch, ein Bulk Insert Tool im Schrank zu haben.

[jobo]

Liegen die Daten als Import vor, wäre das Stichwort 'korreliertes Update'

Code:

UPDATE <Tabelle | View>
   SET <Name einer Spalte> = <Ausdruck aus Spalten,
      Konstanten, Funktionen>
      [, weitere Spaltennamen = Ausdruck]
   [FROM <Tabelle> [INNER | LEFT | RIGHT] JOIN <Tabelle>
   ON <Spalte-1 = Spalte-2>]
   WHERE <Bedingung>

Dieses Verfahren dürfte in keinem etablierten RDBMS zu einer Verletzung von Limitierungen führen. Dieses Verfahren lässt sich auch einfach erweitern, wenn es mehrere Kriterien für den eigentlichen Abgleich gibt. 'Where In ()' ist da je nach System nicht so flexibel.
Bleibt als fragwürdige Hürde nur der Kodierungs-Aufwand für den Import.
Vom Performancespekt her ist die Import/korreliertes Update Lösung garantiert unschlagbar. Wenn es um große Datenmengen geht, setzen wir bspw. vor den Import ein gezipptes Upload.
Je nach Importverfahren /-fähigkeiten der DB ist nicht mal ein wirklicher Import notwendig (Stichwort 'external tables'). Man müllt sich die DB nicht zu und muss nichts anlegen/löschen. Die original csv-Dateien können bei Bedarf zu dokumentarischen Zwecken (gezippt) auf dem Serverfilesystem verbleiben.

[juergen]

@nahpets,

Zitat von nahpets:

Das dürfte die bessere Alternative sein, da es hier keine Einschränkungen für SQL, Where- oder IN-Klausel geben und der geringste Aufwand sein dürfte.

Gestern Nacht hatte ich erst einmal eine Version fertig gestellt, welche mit der IN()-Bedingung arbeitet, aufgeteilt in mehrere "Häppchen". Dabei kann ich nun von "außen" 2 Parameter übergeben:
1. maximale Anzahl der Übergabewerte in der IN() Bedingung (momentan habe ich beim Kunden 1000 eingestellt und das lief heute beim Kunden schon mal problemlos)
2. Die eigentlichen ID's für die IN() Bedingung

Nach diesem Wochenende (Stichwort Borussia ) werde ich auf jeden Fall noch die "bessere" Variante von Furtbichler umsetzen. Schon allein um zu wissen wie das Pervasive eigene BDU-Tool arbeitet.

Zitat von Furtbichler:

Es ist immer praktisch, ein Bulk Insert Tool im Schrank zu haben.

@by jobo,
danke auch für deinen Tipp!
Auf den ersten Blick sieht das für mich nach dem aus, was Furtbichler in Post#2 vorgeschlagen, oder?


Ich bin nun froh dass ich meine Frage hier gestellt hatte, da ich hier 2 interessante neue Ansätze erhalten habe. Vielen Dank dafür!

..

[Furtbichler]

Zitat von juergen:

Ich bin nun froh dass ich meine Frage hier gestellt hatte, da ich hier 2 interessante neue Ansätze erhalten habe. Vielen Dank dafür!

Die DP ist erstaunlich kompetent, fällt mir auch immer wieder auf.

[jobo]

Zitat von juergen:

@by jobo,
danke auch für deinen Tipp!
Auf den ersten Blick sieht das für mich nach dem aus, was Furtbichler in Post#2 vorgeschlagen, oder?

Ja, es ist ein Update, nur anderes Join Verfahren. Eines das ohne Einschränkungen mit großen Datenmengen funktionieren sollte. Der Rest halt Vorgehensweise, Erfahrungswerte bzw. technische Gegebnheiten.