summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/documentation.txt16
1 files changed, 15 insertions, 1 deletions
diff --git a/doc/documentation.txt b/doc/documentation.txt
index a12ccec..dcaf219 100644
--- a/doc/documentation.txt
+++ b/doc/documentation.txt
@@ -80,7 +80,7 @@ evaluiert werden.
==== Transactions
Eine Idee ist es, die Eingabes des Nutzers durch Transactions zu schützen,
-indem vor dem Ausführen der Nutzeranfrage eine Transaction gestartet wird,
+indem vor dem Ausführen der Nutzeranfrage eine Transaktion gestartet wird,
und danach diese immer zurückgerollt (=ROLLBACK) wird:
[source,sql]
@@ -118,12 +118,26 @@ ROLLBACK TRANSACTION;
Um die Anfragen der Nutzer von einander zu trennen, gibt es ebenfalls die
Moeglichkeit jedem Nutzer eine eigene Datenbank zur Verfuedung zu stellen.
+Somit koennte der Nutzer in den Test-Szenarien umfassende aenderungen an der
+Datenbank vornehmen, ohne andere Nutzer dabei zu beeintraechtigen.
+Die Uebungen koennen dann nach einander so konstruiert werden, dass der Nutzer
+die Datenbank in eine bestimmte Richtung hin veraendert.
+
+Der groesste Nachteil liegt im erheblichen Verwaltungsaufwand.
+Es muss bestimmt werden fuer welche Moodle-Nutzer eine Datenbank angelegt wird.
+Zudum muss es Moeglichkeiten geben, die Datenbanken wieder zurueckzusetzen,
+sollte ein Nutzer die Datenbank in einen Zustand bringen, der keine
+erfolgreichen Test mehr erlaubt.
+Alle diese massnahmen wuerden den Entwicklungsaufwand enorm steigern.
==== Keine Schreibrechte
Im einfachsten Fall, bekommen die Nutzer nur Lese-Rechte auf die Datenbank.
Dieses hat den Vorteil, dass der Verwaltungsaufwand fuer das Modul, sowie
der Speicherbedarf der Datenbank veringert wird.
+Mit dieser Variante, lassen sich hingegen nur +SELECT+-Anfragen stellen.
+Andere wichtige Anfragen, wie +UPDATE+, +DELETE+, +CREATE+ und +ALTER+ koennten
+dann nicht innerhalb mit der SQLBox erprobt werden.
== Literatur