Ressourcenplanung/-konflikte und Sperrmechanismen etc.

[asc]

Dieses Thema hatte ich vor etwa einem Jahr bereits zu Access gestellt, im Zuge einer Datenbankumstellung ändern sich die Voraussetzungen aber wesentlich (u.a. wegen Einschränkungen die vorher durch Access bedingt waren), so das ich dies hier neu aufrolle.


Grundsätzlich geht es um eine Ressourcenplanung, sehr vereinfacht ausgedrückt haben wir drei Tabellen: "Termine" (z.B. IdTermin/IdTerminart/Anfang/Ende), "Ressourcen" (IdRessource,Bezeichnung... ; z.B. Personen, Räume etc.) und eine Tabelle die Termine und Ressourcen verknüpft (IdTermin/IdRessource). Jede Tabelle hat noch einen Versionsstempel um schneller auf Änderungen zu prüfen.

Nun soll während ein Termin eingetragen oder verändert wird, kein anderer Benutzer in den Zeitraum des Termins Änderungen (Neuanlage/Bearbeitung/Löschen) machen können, gleichzeitig soll eine komplette Tabellensperrung (falls möglich) vermieden werden.

Im wesentlichen soll das so aussehen:
1. (Bei bestehenden Termin) Daten einlesen [DB-Zugriff]
2. Termin erfassen/bearbeiten
3. Prüfung auf Änderung oder Konflikt [DB-Zugriff]
4. Bei Änderung/Konflikt: Entscheiden was mit Änderung/Konflikt geschehen soll (Änderungen einladen und mit 2 weiterführen, Dennoch speichern...).
5. Termin schreiben (nochmal auf Änderung prüfen, ggf. zurück zu 4.) [DB-Zugriff]

Sofern wir es vermeiden können, wollen wir auf komplette Tabellensperren verzichten (und wenn müssen wir diese, der Schnittstelle wegen, auf eine Datensatzsperre in eine Hilfstabelle oder ähnliches beschränken). Nur wie kann man z.B. das Einfügen eines Datensatzes in einen Zeitraum unterbinden?


Diese Problematik wird noch etwas erschwert dadurch, das die Konfliktprüfung "weich" ist. Sprich: Eine Ressource darf in Zukunft ggf. mehrfach verplant werden, aber nur mit Rückfrage. Dann muss ich noch ein Mechanismus finden, der sicherstellt das im Konfliktfall der Anwender entscheiden kann die Konflikte zu ignorieren, und beim anschließenden Schreiben muss dann natürlich auch sichergestellt sein, das keine neuen Konflikte aufgetreten sind (oder die Frage wiederholt wird).

[hwoess]

...Nun soll während ein Termin eingetragen oder verändert wird, kein anderer Benutzer in den Zeitraum des Termins Änderungen (Neuanlage/Bearbeitung/Löschen) machen können...

Kann man das genauer definieren? Ist das der Zeitraum den die Datenbank zum Schreiben braucht (also NACHDEM der Benutzer auf Speichern gedrückt hat) oder ab dem Zeitpunkt ab dem ein Benutzer einen Datensatz in den Edit-Status setzt bis dahin, wo der Datensatz geschrieben oder die Änderung verworfen wurde?
Irgendwelche Sperren im Fall zwei würde ich vom Konzept her falsch halten. Aber mal sehen ...

bye,
Helmut

[asc]

Kann man das genauer definieren? Ist das der Zeitraum den die Datenbank zum Schreiben braucht (also NACHDEM der Benutzer auf Speichern gedrückt hat) oder ab dem Zeitpunkt ab dem ein Benutzer einen Datensatz in den Edit-Status setzt bis dahin, wo der Datensatz geschrieben oder die Änderung verworfen wurde?

Ich versuche hierzu noch einmal ausführlicher die Hintergründe zu erklären:

Wir haben eine Termintabelle die im wesentlichen aus einem Beginn und Ende (Zeitraum) besteht, mit n zugeordneten Ressourcen. Nun darf eine Ressource a aber zu einem Zeitraum b nicht mehrfach vorkommen, es sei den, der Benutzer (sofern er dazu über die nötigen Rechte verfügt) akzeptiert dies explizit.

Wenn nun während des Schreibvorganges (der zudem eine grundlegende Änderungsprüfung enthalten muss) jemand anderes einen Termin in diesem Termin-Zeitraum ändert oder hinzufügt (kritisch ist hierbei eigentlich nur ob neue Ressourcenzuordnungen in dem Termin-Zeitraum hinzukommen, die mit den Ressourcen des zu schreibenden Termins kollidieren), wäre die Prüfung erneut durchzuführen, und der Termin dürfte nicht gespeichert werden.

An sich ist es mir egal mit welchen DB-Mitteln ich so etwas abbilden kann, in unser derzeitigen Anwendung wird für diesen Vorgang eine Tabellensperre gesetzt. Hierzu ist aber zu sagen, das wir bislang nur wenige Anwender haben (in der Regel arbeiten bislang maximal 5 Benutzer gleichzeitig an der Datenbank - dies soll sich aber in der Zukunft ändern), zum anderen ist dieser Schreibvorgang üblicherweise recht schnell beendet.


Ich besitze leider nur sehr grundlegende DBA-Fähigkeiten (womit ich aber dennoch "der" Experte bei uns bezüglich Datenbanken bin), und kenne nicht alle Möglichkeiten. Rein naiv betrachtet würde ich dies wie folgt lösen:

1. Transaktion öffnen, und irgendeine Form der Schreibsperre setzen (um dies nicht zwangsweise über die gesamte Datenbank zu erstrecken, kam mir die Idee eine weitere Tabelle einzufügen wo für jeden Tag eine Spalte existiert, und den/bzw. die betroffenen Tage in den Editierzustand zu versetzen - In der Hoffnung das ich so wenigstens nur einzelne Tage für andere kurzzeitig blockere).

2. Über einen Select ermitteln ob einer der betroffenden Ressourcen in dem Zeitraum verplant ist, und wenn ja diese ermitteln (für einen Hinweisdialog) und den höchsten betroffenen Zeitstempel zwischenspeichern. Falls bereits ein solcher Dialog angezeigt wurde, und der Benutzer die Konflikte akzeptiert hätte, würde dieser Zeitstempel für diesen Select zum begrenzen auf zwischenzeitliche Änderungen verwendet werden.

Im Falle mindestens eines Treffers wird die Transaktion beendet, dem Benutzer ein Dialog angezeigt, und beim akzeptieren der Konflikte der Vorgang mit 1 beginnend wiederholt.

3. Änderungen schreiben, Transaktion beenden (& Sperre entfernen).


Falls es bessere Möglichkeiten gibt, nur her damit. Dies oben ist eine absolute Ausnahme in unseren Programm, an anderen Stellen können wir damit leben das beim Schreiben entweder der letzte gewinnt, oder das man eine Änderungsprüfung zumindest auf den jeweiligen Datensatz beschränken muss (was ja durchaus mittels einer "timestamp"-Spalte, und dem Eingrenzen auf die ausgelesene Version beim Schreiben gehen sollte).