diff --git a/doc/decisions/ADR-sqlite.asciidoc b/doc/decisions/ADR-sqlite.asciidoc index 0fdfb539705f50e051b8cef847dcc49d614f3c99..2de46b85762073eb576849def83dee7a931caa2a 100644 --- a/doc/decisions/ADR-sqlite.asciidoc +++ b/doc/decisions/ADR-sqlite.asciidoc @@ -32,7 +32,7 @@ Proposed Bisher wird ein Script generiert, welches SQL für eine PostgreSQL-Datenbank erzeugt. Dies zieht folgende Probleme nach sich: 1. das SQL-Script wird durch die serialisierte und textuelle Darstellung der Daten sehr groß, insbesondere, weil jedes Jahr mehr und mehr AIPs zu berücksichtigen sind. -2. es muss eine extra Postgres-Datenbank aufgesetzt werden +2. es muss eine extra PostgreSQL-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. @@ -41,9 +41,9 @@ Mit der Nutzung von SQLite hätte man zum einen sofort eine lauffähige Datenban // was folgt aus Entscheidung -1. 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. +1. Durch die direkte Verwendung von SQLite entfällt der Erhalt der Eigenschaft "direkt menschenlesbar". Durch die optionale Möglichkeit der Generierung des SQL-Scriptes wird dieser Nachteil abgefedert. -2. Ein Nachteil ist, dass auf SQLite nicht ohne weiteres mehrere Programme von unterschiedlichen Rechnern zugreifen können. +2. Auf SQLite können nicht ohne weiteres mehrere Programme von unterschiedlichen Rechnern zugreifen. 3. 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.