Nicht mehr als nötig

Auch für die Performance gilt natürlich: Je weniger Daten Sie tatsächlich einlesen (also in den internen Strukturen für den Mapping-Vorgang speichern), desto schneller geht es. Klopfen Sie daher Ihre Aufgabenstellung daraufhin ab, ob Sie wirklich alle Daten einlesen und mappen müssen, oder ob sich nicht Teile davon einfach ignorieren lassen. Detaillierte Informationen dazu finden Sie ja im Speicher-Kapitel.

Einfacher Datenmapper

Um es gleich vorwegzunehmen: Der einfache Datenmapper ist nur in wenigen Fällen praktisch nutzbar. Der Hauptgrund dafür ist, dass bei seiner Verwendung keine Pfade und auch keine hierarchischen Knotenstrukturen benutzt werden können, was bei den meisten auch nur etwas komplexeren Datenstrukturen ganz einfach notwendig ist. Auch Berechnungsfelder sind hier nicht benutzbar.
Wenn Sie aber auf all das verzichten können, holen Sie mit dem einfachen Mapper eine ganz gewaltige Performance-Steigerung heraus. Wenn Sie sich nicht sicher sind, versuchen Sie's einfach mal. Sieht das Ergebnis gut aus, nehmen Sie den einfachen Mapper, wenn Sie damit nicht weiterkommen, schalten Sie wieder auf den erweiterten um.

Betrachten wir wieder einmal unsere Kundendaten, die wir nun einfach von einer Datenbank in eine einfache Excel-Tabelle übertragen wollen.

Die Strukturen dazu sehen wie folgt aus.

Quellstruktur:

Zielstruktur:

Wie schon früher geschrieben, wird für jede Zeile aus der Datenbank ein Datenblatt erzeugt. Wenn Sie sicher sind, dass Sie aufgrund der Datenmenge oder der Zeit, zu der das Profil läuft, keine Speicherprobleme bekommen werden, können Sie das unterbinden, indem Sie die Eigenschaft Erzwinge ein einzelnes Datenblatt (nur für manchen Dokumentenarten verfügbar, siehe jeweils dort) setzen. Das kann noch einen kleinen Geschwindigkeitsvorteil bringen. Wenn Sie sich da nicht so sicher sind: Lassen Sie es! Nebenbei bemerkt: Natürlich können Sie dann auch Funktionen wie isFirstRecord nicht sinnvoll einsetzen, da es ja nun mal nur einen Record (=Datenblatt) gibt. Dieser lässt sich noch durch ein Variablen-Konstrukt ersetzen, bei isLastRecord wird das allerdings schon schwieriger.

In diesem Beispiel brauchen Sie nun wirklich keine Pfade, Hierarchien usw. Sie wollen ja nur jede Zeile, die aus der Datenbank kommt, in eine Zeile der Excel-Datei umsetzen. Einfacher geht es fast nicht.

Und Excel schafft ja sogar im alten Dateiformat immerhin über 60.000 Zeilen (das neue .xlsx hat diese Begrenzung nicht mehr). Bei einer kompletten Kundenstamm-Übernahme können auch schon mal einige tausend oder zehntausend zusammenkommen. Verwenden Sie hier den einfachen statt des erweiterten Datenmappers, können Sie ganz schnell über 50, manchmal bis zu 70 Prozent an Zeit sparen. Und den Speicher schont es, ganz nebenbei, auch noch ein Stück weit. Stellen Sie sich jetzt noch vor, dass Sie einige Millionen Datensätze von einer Datenbank in eine andere schaufeln wollen, kann die Zeitersparnis für den Mapping-Vorgang im Bereich von Stunden liegen. Natürlich ist hier dann auf keinen Fall ein einziges Datenblatt zu verwenden, zusammen mit dem TokenStreamSplitter, der schon im Speicher-Kapitel beschrieben wurde, geht es aber durchaus.

SQL-Knoten

Knoten der Zielstruktur haben die Eigenschaft "Gilt nur für SQL".

Der Sinn dieser Eigenschaft ist der folgende: Es gibt Fälle, in denen einerseits Daten in eine Datenbank geschrieben werden sollen, andererseits aber auch z. B. eine Datei erstellt werden soll. Und diese Datei soll nicht dieselben Daten enthalten, die in die Datenbank geschrieben wurden. Zum Beispiel nur ein paar Summen, die Anzahl der geschriebenen Datensätze usw., aber doch bitte nicht tausende von Zeilen mit den Daten, die eigentlich nur in die Datenbank geschrieben werden sollen.

In diesem Fall setzt man die Eigenschaft Gilt nur für SQL der Knoten, die für die Datenbank-Tabellen zuständig sind, auf Ja, sodass bei allen folgenden Schritten (schon bei der Integration Unit) die Daten in diesen Knoten nicht mehr berücksichtigt werden.

Das ist eine feine Sache, hat allerdings einen Haken: Jedes einzelne Datenblatt wird nach Phase 4 (SQL) in die Hand genommen, also bei Swapping auch eingelagert, alle Daten dieser Knoten entfernt, und dann bei Swapping auch wieder ausgelagert. Das kostet. Daher sollten Sie diese Eigenschaft nur dann auf Ja setzen, wenn Sie sie tatsächlich benötigen, wie anfangs beschrieben. Ansonsten setzen Sie dort bitte immer Nein.