// Gründe, Randbedingungen, die zur Entscheidung führen
Bisher wird ein Script generiert, welches SQL für eine PostgreSQL-Datenbank erzeugt. Dies zieht folgende Probleme nach sich:
1. das SQL-Script wird sehr groß, inbesondere, weil jedes Jahr mehr und mehr AIPs zu berücksichtigen sind
2. es muss eine extra Postgres-Datenbank aufgesetzt werden
3. das SQL Script ist von der Datenbank entkoppelt. Ob das Script tatsächlich funktioniert, kann erst bei Einspielen des Scripts in die Datenbank geprüft werden
Mit der Nutzung von SQLite hätte man zum einen sofort eine lauffähige Datenbank, die nicht erst administriert werden muss. Zum anderen erspart man sich den Zwischenschritt der SQL-Script Generierung.
== Konsequenzen
// was folgt aus Entscheidung
Durch die direkte Verwendung von SQLite entfällt der Erhalt der Eigenschaft "direkt lesbar". Durch die optionale Möglichkeit der Generierung des SQL-Scriptes wird dieser Nachteil abgefedert.
Berücksichtigt werden sollte, dass es uU. möglich ist, dass eine SQLite-Datenbank-Datei nur mit bestimmten Versionen lesbar ist. Die Nutzbarkeit der SQLite-Datenbank muss durch regelmäßige Tests sichergestellt werden.
