Quick and Dirty?

Vor einigen Jahrzehnten - in der Computerwelt quasi eine Ewigkeit - war alles irgendwie ganz anders. Programmierer tüftelten tagelang darüber, wie man das Programm so umformulieren konnte, dass es noch ein bisschen schneller laufen oder mit weniger des damals noch extrem teuren Speichers auskommen konnte. Dass der Programmcode dann für Dritte weitgehend unverständlich war, wurde als notwendiges Übel in Kauf genommen.

Seit dieser Zeit hat sich viel geändert. Die Hardware wurde immer schneller und leistungsfähiger, jedes einfache Gerät ist mit Speichermengen ausgestattet, die seinerzeit nicht einmal bei den größten Systemen verfügbar waren. Und auch bei der Softwareentwicklung haben sich ganz entscheidende Änderungen durchgesetzt.

Nun ist die optimale Wartbarkeit bei möglichst wenigen Programmfehlern das höchste Ziel. Dass diese Entwicklungs-"Philosophie" grundsätzlich zu langsameren Programmen und höherem Ressourcenbedarf führt, wird gerne in Kauf genommen, schließlich entwickelt sich die Technologie immer weiter. Das betrifft eigentlich jede Art von Software, auch natürlich Laborinformationssysteme (LIMS).

Doch die Praxis stimmt leider nicht immer mit der Theorie überein, bei komplizierten oder umfangreichen Abfragen treten doch häufig recht deutliche Wartezeiten auf, die für Unmut bei den LIMS-Anwendern sorgen. In den allermeisten Fällen liegt die Ursache beim verwendeten Datenbanksystem, die üblicherweise mit der Abfragesprache "SQL" arbeiten. SQL ist vom Prinzip her sehr elegant aufgebaut, das LIMS teilt dem Datenbanksystem nur mit, welche Daten es erwartet - wie dieses dann die Suche aufbauen soll, entscheidet das Datenbanksystem selbst. Das LIMS holt dann einfach die komplett aufbereiteten Daten ab.

So elegant und gut wartbar dieses Konzept ist, führt es aber doch - zumindest wenn das Budget für leistungsfähige Hardware nicht unbegrenzt ist - oft zu längeren Abfragezeiten, die die Anwender verärgern. Mit kleinen "nicht ganz sauberen" Tricks kann man hier viel erreichen. "Nicht ganz sauber" geht hier auf Kosten der Übersichtlichkeit und Wartbarkeit, nicht natürlich der Funktionsfähigkeit selbst.

Ein Beispiel dazu: das Laborinformationssystem (LIMS) speichert den Probentyp jeder Probe (Abwasser, Trinkwasser, Boden etc.) als Zahl z.B. zwischen 1 und 10. Um in einer Tabelle aber dann nicht diese Zahl, sondern eben "Abwasser" o.ä. anzuzeigen, wird die Abfrage im "idealtypischen" System einfach so formuliert, dass die Datenbank selbst die Bezeichnung für die Nummer sucht. Bei großen Listen und beschränkten Hardware-Ressourcen (oder auch eingeschränkten, z.B. kostenlosen Versionen des Datenbanksystems) kann dies aber zu längeren Abfragezeiten führen. Eine sehr effiziente, wenn auch eben nicht "elegante" Alternative wäre, dass das LIMS nur die Nummern anfordert und sich die Übersetzungstabelle zwischen Nummern und Bezeichnungen einmalig am Anfang einliest und dann selbst ohne Einbindung des Datenbanksystems anwendet. Das ist zweifellos weniger übersichtlich und schlechter zu warten, vermeidet aber wiederum Ärger und Zeitverluste durch lange Abfragezeiten.

Letztendlich sollte man solche Fragen immer in Abstimmung zwischen Laborleitung, Key-Usern und den LIMS-Entwicklern klären, um in der vorgegebenen Situation den bestmöglichen Kompromiss zwischen Wartbarkeit und Bedienbarkeit zu finden.

< Früherer Beitrag