Ich hab in meinem Beispiel explizit eine Stored Procedure verwendet, weil ein Datenimport in 90 % der Fälle leider nicht nur mal eben mit "update or insert" oder merge über Primary Key ausreicht, auch wenn meine Demo Prozedur nicht mehr macht. Daher läuft bei mir der Import immer zweistufig, erst mal die Daten rein in die
DB, dann in der
DB via SP verteilen. Und das hat sich in erster Linie deshalb bewährt, weil das mit SP eben so schnell ist.
Wenn du die DB1 Demo
DB auf deinem Rechner hast, dann starte einfach mal die Prozedur initall mit dem Parameter 10000. Damit werden aus den TMP_* Tabellen Demodaten generiert. Wenn man jetzt mal die TMP_* Tabellen als Import und die anderen Tabellen als finale Daten betrachtet, dann sieht man, was im Rahmen einer SP an speed möglich ist, zumindest bei Firebird, ich weiß von anderen Plattformen, wo SP weniger verbreitet sind, weil meistens auch nicht so schnell.
konkrete Daten und Performanceanalyse aus Firebird/IBExpert:
Code:
BEFEHL
execute procedure INITALL(10000);
Query
------------------------------------------------
Plan
------------------------------------------------
Query Time
------------------------------------------------
Prepare : 0,00 ms
Execute : 8.612,00 ms
Avg fetch time: 0,00 ms
Memory
------------------------------------------------
Current: 337.372.048
Max : 337.833.024
Buffers: 20.000
Operations
------------------------------------------------
Read : 114
Writes : 570
Fetches: 3.570.581
Enchanced Info:
+--------------------------+-----------+-----------+-------------+---------+---------+---------+
| Table Name | Records | Indexed | Non-Indexed | Updates | Deletes | Inserts |
| | Total | reads | reads | | | |
+--------------------------+-----------+-----------+-------------+---------+---------+---------+
| CUSTOMER| 0 | 2 | 0 | 0 | 0 | 10000 |
| INVENTORY| 0 | 70476 | 0 | 35238 | 0 | 10000 |
| ORDERLINE| 0 | 0 | 0 | 0 | 0 | 35238 |
| ORDERS| 0 | 45238 | 0 | 10000 | 0 | 10000 |
| PRODUCT| 0 | 35240 | 0 | 0 | 0 | 10000 |
| TMP_ADR| 0 | 10000 | 0 | 0 | 0 | 0 |
| TMP_CITY| 0 | 9999 | 0 | 0 | 0 | 0 |
| TMP_FN| 0 | 9996 | 0 | 0 | 0 | 0 |
| TMP_FN2| 0 | 19959 | 0 | 0 | 0 | 0 |
| TMP_LN| 0 | 9994 | 0 | 0 | 0 | 0 |
| TMP_LN2| 0 | 19962 | 0 | 0 | 0 | 0 |
| TMP_STATE| 0 | 9895 | 0 | 0 | 0 | 0 |
| TMP_TITLEWORD| 0 | 29987 | 0 | 0 | 0 | 0 |
+--------------------------+-----------+-----------+-------------+---------+---------+---------+
oder mit anderen Worten:
Während der Ausführung der Prozedur wurden 391224 individuelle Insert/Update/Delete Statements
ausgeführt und gedauert hat das 8,6 Sekunden. Das die zigtausend Aufrufe von Zufallszahlen in
der Prozedur auch noch Zeit kosten ist klar, wenn man sich der Code in der Prozedur INITALL
ansieht.
Meßergebnis sind auf dem Wege aber über 45000 Operationen pro Sekunde, die man im Rahmen einer
Stored Procedure problemlos erreichen kann. Damit lassen sich auch richtig große Datenmengen
in vertretbaren Zeiten verarbeiten (Ich weiß von einem Kunden im Iran, der eine Firebird
DB mit 15TB betreibt, normal sind aber meistens Datenbankgrößen zwischen 100MB und 1TB).
Ich wollte nur noch mal deutlich machen, warum ich im Tutorial den vermeindlichen Umweg über
die SP gegangen bin, wenn man alles mit einer Zeile Code erledigen könnte, dann hätten die
meisten von uns keinen Job.
So sähe der gleich Befehl in Firebird und einigen anderen DBs übrigens als
SQL ohne SP aus
Code:
merge into product p
using import_product
ip
on p.id =
ip.id
when matched then
update set CATEGORY_ID =
IP.CATEGORY_ID,
TITLE =
IP.TITLE,
ACTOR =
IP.ACTOR,
PRICE =
IP.PRICE,
SPECIAL =
IP.SPECIAL
when not matched then
insert (ID, CATEGORY_ID, TITLE, ACTOR, PRICE, SPECIAL)
values (
IP.ID,
IP.CATEGORY_ID,
IP.TITLE,
IP.ACTOR,
IP.PRICE,
IP.SPECIAL)