Schlüsselverzeichnisse für VBA-Programme

Bei der Entwicklung von Software, die ein bestimmtes Maß an Komplexität erreicht hat, stellte ich mir früher des Öfteren die Frage, wie die Datenhaltung in Schlüsselverzeichnissen am besten aufzubauen ist. Im Laufe der Zeit habe ich einige Möglichkeiten ausprobiert. Insgesamt haben sich dabei 3 Varianten herauskristallisiert, die ich hier mit deren Vor- und Nachteilen vorstellen möchte.

hardkodiertes Schlüsselverzeichnis

Diese Variante zeichnet sich dadurch aus, dass es an sich kein separates Schlüsselverzeichnis gibt. Stattdessen gibt es eine Funktion, die in „ihrem Bauch“ die Funktionalität eines Schlüsselverzeichnisses nachbildet. Das bedeutet, dass die Funktion einen Übergabeparameter (Schlüssel) erwartet, zu dem ein Wert aus dem Verzeichnis als Rückgabewert geliefert werden soll. Ein Anwendungsbeispiel könnte dafür sein, dass wir ein paar Länderbezeichnungen anhand eines Kürzels zu ermitteln haben. So eine Funktion könnte folgendermaßen aussehen:

public function getLandKlartext(landKuerzel as String) as String

	dim klartext as string
	klartext=""

	select case landKuerzel
		case: "DE"
			klartext="Deutschland"
		case: "AT"
			klartext="Österreich"
		case: "CH"
			klartext="Schweiz"
	end select
	
	getLandKlartext=klartext
	
end function

Bei kleinen Schlüsselverzeichnissen mit wenigen Einträgen, die sich so gut wie nie ändern, hat diese Variante durchaus ihren Charme, da sie sehr schnell und einfach umsetzbar ist. Jedoch kommt diese Variante schnell an ihre Grenzen. Bei einer großen Anzahl an Einträgen würde zum einen die Übersichtlichkeit leiden – wer möchte schon ein Select Case-Konstrukt mit 400 Fällen programmieren :-). Zum anderen würde jede Änderung der Inhalte im Schlüsselverzeichnis auch eine Anpassung und die Auslieferung des Programms nach sich ziehen.

Um diese Nachteile auszugleichen, kann die Variante 2 in Betracht gezogen werden

Excelmappe-Schlüsselverzeichnis

Bei dieser Variante wird der Inhalt des Schlüsselverzeichnisses in einer normalen Excelmappe in tabellarischer Form abgelegt. Das Auslesen dieser Daten erfolgt in der Regel sequentiell – mit einer FOR-Schleife werden die Schlüsselwerte solange durchlaufen, bis der Eintrag mit dem gesuchten Schlüssel gefunden wurde. Wenn es sich dabei um ein großes Verzeichnis mit vielen Einträgen handelt, welches häufig aufgerufen wird, würde ich empfehlen, alle Elemente einmalig in eine Dictionary-Datenstruktur einzulesen. So kann man sich dann die sequentielle Suche sparen. Man greift dann auf den benötigten Satz direkt mit seinem Schlüssel zu und erhält so seinen Wert.

Der Vorteil dieser Variante ist, dass die Pflege des Schlüsselverzeichnisses sehr einfach ist – so als würde man eine normale Excelmappe bearbeiten. Handelt sich sich um ein fachliches Schüsselverzeichnis, kann der Kunde das Schlüsselverzeichnis selbst pflegen, sodass eine Anpassung und Auslieferung durch den Entwickler nicht nötig ist.

Doch auch diese Variante hat ihre Grenzen. Haben die Daten eine stark verzweigte und komplexe Hierarchie, ist die Handhabung solcher Daten in einer Excelmappe relativ problematisch. Der zweite Nachteil dieser Variante ist, dass die eingegebenen Daten im Schlüsselverzeichnis auf ihre Plausibilität zu prüfen sind. Dies treibt natürlich den Programmieraufwand bei einer hohen Anzahl an verzweigte Attributen schnell in die Höhe.

Und zu guter Letzt hat Excel auch mit korrekt eingegeben Daten auch seine Probleme:-). Man denke nur an die führenden Nullen bei Postleitzahlen, die gerne unterdrückt werden, wenn man die betreffende Zeile nicht als Text formatiert hat. Oder wenn Excel aus eingegebenem 147E5 automatisch ein 1,47E07 macht. Bei solchen ungewollten automatischen Formatanpassungen ist klar, dass ohne eine Plausibilitätsprüfung die Anzahl von Fehlverarbeitungen definitiv zunimmt.

All diese Nachteile haben mich dazu bewogen, bei größeren Projekten zur 3. Variante zu greifen.

XML-Schlüsselverzeichnis

Diese Variante hat zwar den Nachteil, dass eine zusätzliche Datei benötigt wird und das Auslesen etwas komplexer als bei einer Excelmappen ist. Bei größeren Projekten jedoch fällt dies aus meiner Sicht kaum ins Gewicht.

Der größte Vorteil ist für mich die Tatsache, dass ich mit XML die Schlüsselverzeichnisse beliebiger Komplexität bauen kann, siehe Beispiel unten. Anders als bei Excel bin ich bei einer hierarchischen Struktur mit XML sehr flexibel, vor allem was die Verschachtelungstiefe der Einträge angeht.

<laender-verzeichnis>
	<land kuerzel="DE">
		<lang-bezeichnung>Deutschland</lang-bezeichnung>
		<waehrung>EUR</waehrung>
		<niederlassungen>
			<niederlassung>Berlin</niederlassung>
		</niederlassungen>
	</land>
	<land kuerzel="AT">
		<lang-bezeichnung>Österreich</lang-bezeichnung>
		<waehrung>EUR</waehrung>
		<niederlassungen>
			<niederlassung>Wien</niederlassung>
			<niederlassung>Graz</niederlassung>
		</niederlassungen>
	</land>
	<land kuerzel="CH">
		<lang-bezeichnung>Schweiz</lang-bezeichnung>
		<waehrung>CHF</waehrung>
		<niederlassungen>
			<niederlassung>Bellinzona</niederlassung>
			<niederlassung>Zürich</niederlassung>
			<niederlassung>Lugano</niederlassung>
			<niederlassung>Bern</niederlassung>
			<niederlassung>Luzern</niederlassung>
		</niederlassungen>
	</land>
</laender-verzeichnis>

Der weitere Punkt, der aus meiner Sicht für diese Variante spricht, ist, dass in XML die Validierung der darin enthaltenen Daten relativ einfach möglich ist. So lassen sich (entweder direkt in der XML-Datei oder in einer separaten XSD-Datei), für alle Inhalte entsprechende Regeln definieren, wie die Daten zu strukturieren sind und welche Werte diese annehmen dürfen. So kann ich zum Beispiel gleich hinterlegen, dass Länderkürzel immer großgeschrieben werden müssen und maximal 3 Buchstaben enthalten dürfen. Ebenfalls lässt sich einstellen, dass die Schlüsselwerte in der XML-Datei eindeutig sein müssen. Verstößt so eine XML-Datei gegen die definierten Regeln, wird beim deren Einlesen ein Fehler geworfen, der als Beschreibung genau die Stelle in der XML-Datei aufführt, die unerlaubte Werte hat. Alles in einem ist es ein sehr mächtiges Werkzeug. Aus meiner Sicht lohnt es sich da definitiv, etwas mehr Gedanken über die Validierungsregeln zu machen, vor allem, wenn es sich um ein Schlüsselverzeichnis handelt, welches sehr oft vom Kunden oder vom Entwickler gepflegt wird. Denn bei solchen Anpassungen können immer wieder Flüchtigkeitsfehle oder Zahlendrehen passieren, die mit Hilfe der Validierung in den meisten Fällen erkannt werden.

Und der letzte Vorteil, den nicht nicht unerwähnt lassen möchte, ist XPath. Mit dieser Abfragesprache lassen sich bequem Abfragen in der XML-Datei durchführen. So kann ich mir beispielsweise alle Länderknoten aus dem Verzeichnis liefern, die mehr als 7 Niederlassungen  haben. Oder auch alle Daten zu dem Land mit dem Kürzel „DE“. Ebenso kann ich die Abfrage spezifizieren, dass mir diese nicht alle Daten, sondern nur ein einzelnes Attribut liefert. Somit entfällt die größtenteils die Notwendigkeit, die Daten sequentiell lesen zu müssen.

Fazit

Ich glaube, in diesem Beitrag liest man schon deutlich heraus, welche Variante ich für komplexere Datenstrukturen bevorzuge und warum. Nicht desto trotz haben alle 3 Varianten, sowie die Varianten, die ich hier nicht vorgestellt habe, ihre Daseinsberechtigung und ihre Anwendungsfälle, zu denen sie am besten passen.

1 thought on “Schlüsselverzeichnisse für VBA-Programme

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.