diff options
| -rw-r--r-- | doc/documentation.txt | 20 |
1 files changed, 12 insertions, 8 deletions
diff --git a/doc/documentation.txt b/doc/documentation.txt index dcaf219..7756676 100644 --- a/doc/documentation.txt +++ b/doc/documentation.txt @@ -68,7 +68,7 @@ Für Moodle ist ein integriertes Video-Plugin verfügbar. == SQLBox ``SQLBox'' ist ein Moodle-Modul, welches im Rahmen des Mulimedia-Projekts -entstenden ist. +entstanden ist. === Sandbox für User-Queries @@ -79,7 +79,7 @@ evaluiert werden. ==== Transactions -Eine Idee ist es, die Eingabes des Nutzers durch Transactions zu schützen, +Eine Idee ist es, die Eingaben des Nutzers durch Transaktionen zu schützen, indem vor dem Ausführen der Nutzeranfrage eine Transaktion gestartet wird, und danach diese immer zurückgerollt (=ROLLBACK) wird: @@ -96,7 +96,7 @@ ROLLBACK TRANSACTION; ---- Ein Nutzer könnte aber aus dieser Sandbox ausbrechen, in dem er die gestartet -Transaktion beendet, den Datensatz manipuliert und dann eine neue Transaction +Transaktion beendet, den Datensatz manipuliert und dann eine neue Transaktion startet: [source,sql] @@ -117,24 +117,28 @@ ROLLBACK TRANSACTION; ==== Separate Datenbank 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 +Moeglichkeit jedem Nutzer eine eigene Datenbank zur Verfuegung 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, +Zudem 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. +Dabei muesste geklaert sein, in welchem Zustand diese geschehen muesste. +Entweder in einen Zustand indem der Nutzer an der naechsten noch offenen Aufgabe +weiter arbeiten kann, oder in eine Grundzustand, bei dem der Nutzer alle +Aufgaben von neuem erfuellen muss. +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. +der Speicherbedarf der Datenbank verringert 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. |