Bei der Entwicklung von Software gelange ich immer wieder an den Punkt, an dem ich zur Verwaltung von Programmparametern Schlüsselverzeichnisse benötige. Im Laufe der Zeit habe ich einige Möglichkeiten ausprobiert, von denen ich in diesem Beitrag die drei häufigsten mit deren Vor- und Nachteilen vorstellen möchte.

Funktion als Schlüsselverzeichnis

Diese Variante zeichnet sich dadurch aus, dass es im Grunde genommen kein separates Schlüsselverzeichnis in Dateiform gibt. Seine Rolle übernimmt eine Funktion, die Programmparameter in „ihrem Bauch“ beinhaltet. Die Funktion erwartet einen Übergabeparameter (Schlüssel), zu dem sie den passenden Wert liefert. Ein Anwendungsbeispiel könnte dafür ein Verzeichnis mit ein paar Ländern sein, die anhand des Kürzels zu ermitteln sind. So könnte die Funktion 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 Schlüsselverzeichnissen mit wenigen Einträgen, die sich sehr selten ändern, hat diese Variante durchaus Charme. Wenn jedoch die Anzahl an Einträgen im Laufe der Zeit steigt, leidet darunter die Übersichtlichkeit – wer möchte schon ein Select Case-Konstrukt mit 400 Fällen pflegen :-). Zum anderen würde jede Änderung der Schlüssel bzw. deren Ausprägungen auch eine Auslieferung des Programms nach sich ziehen.

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

Excel-Schlüsselverzeichnis

Bei dieser Variante wird das Schlüsselverzeichnisses in einer normalen Exceltabelle 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 umfangreiches Verzeichnis handelt, welches häufig aufgerufen wird, empfehle ich, alle Elemente einmalig in eine Dictionary-Datenstruktur zu überführen. So kann man sich dann die sequentielle Suche sparen und nach dem initialen Einlesen auf die benötigten Sätze direkt mit ihren Schlüsseln zugreifen.

Diese Variante zeichnet sich durch einfache Datenpflege aus – so als würde man eine normale Exceltabelle bearbeiten. Dies gilt allerdings nur bei flachen strukturierten Daten. Haben die Daten eine stark verzweigte und komplexe Hierarchie, ist deren Handhabung in einer Exceltabelle relativ problematisch. Weiterer Nachteil ist die Notwendigkeit, die eingegebenen Daten im Schlüsselverzeichnis auf ihre Plausibilität zu prüfen. Dies kann den VBA-Programmieraufwand schnell in die Höhe treiben.

Und zu guter Letzt hat Excel auch mit korrekt eingegeben Daten auch seine Problemchen. Man denke nur an die führenden Nullen bei Postleitzahlen, die gerne unterdrückt werden, wenn man die aufnehmende Zelle nicht als Text formatiert ist. Oder wenn das eingegebene 147E5 automatisch zu einem 1,47E07 wird. 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 mittleren und größeren Projekten fast immer 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 und bietet dafür 3 Vorteile.

<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>

Einsatzzweck

Komplexe Strukturen und Hierarchien sind genau das, wofür XML vor mehr als 20 Jahren konzipiert wurde. Anders als bei Excel ist man bei einer hierarchischen Struktur mit XML sehr flexibel, vor allem was die Verschachtelungstiefe der Einträge angeht.

Plausibilitätsprüfungen mit XSD

Im Gegensatz zu Excel oder VBA stellt XML mit eigener Beschreibungssprache XSD ein sehr mächtiges Werkzeug bereit, um Daten auf ihre Gültigkeit zu validieren. So lässt sich damit nicht nur genau festlegen, welche Regeln für einzelne Attribute gelten. Es ist möglich, auch der XML-Struktur einen Rahmen vorzugeben.

Um beim Länderbeispiel zu bleiben, können wir in der XSD-Datei beispielsweise hinterlegen, dass die Länderkürzel immer aus zwei Großbuchstaben bestehen müssen und pro Land mindestens eine Niederlassung aufgeführt werden muss, die nicht mehrfach vorkommen dürfen. Verstößt das XML-Schlüsselverzeichnis gegen eine der definierten Regeln, erfährt man, welche Stelle genau nicht korrekt ist. Wie das funktioniert, habe ich in diesem Beitrag beschrieben. Aus meiner Sicht lohnt es sich da definitiv, etwas mehr Gedanken über die Validierungsregeln zu machen, vor allem, wenn das Schlüsselverzeichnis laufend gepflegt wird. Denn dabei können immer wieder Flüchtigkeitsfehler oder Zahlendreher passieren, die durch die Validierung in den meisten Fällen erkannt werden.

Inhaltsselektionen mit XPath

Mit XPath steht uns als Entwickler eine sehr mächtige Abfragesprache (ähnlich wie SQL in relationalen Datenbanken) zur Verfügung. So kann ich mir beispielsweise alle Länderknoten aus dem Verzeichnis liefern lassen, die mehr als 7 Niederlassungen  haben. Oder alle Daten zum Land mit dem Kürzel „DE“. Ebenso kann ich die Abfrage spezifizieren, sodass 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. Ein praktisches Beispiel zum XPath-Einsatz habe ich in diesem Beitrag zum Thema Auslesen von Kontoauszugsdateien beschrieben.

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 3 Varianten je nach Einsatzzweck und Softwarekomplexität alle ihre Daseinsberechtigung.