Gleichzeitiger Zugriff vs. Löschen

Hallo,

ich habe folgendes Problem und wollte fragen, wie ich das am Besten lösen sollte:

Ausgangssituation:

Ich habe eine Anwendung in der gibt es Benutzer, die sich eine Liste aus mehreren Artikeln zusammenstellen können.

Nun hat der Benutzer folgende Möglichkeiten:

  • Die Artikel in der Liste bestellen.
  • Die Artikelliste für sich speichern.
  • Eine vorhandene Artikelliste laden und bearbeiten.

Dann gibt es noch den Superuser, dieser soll Artikel löschen können ohne Rücksicht dadrauf, ob diese in irgendwelchen Artikellisten gespeichert wurden oder nicht.(Daher kommen Sperren hier schon mal nicht infrage)

Es werden also alle Fremdschlüsselreferenzen auf diesen Artikel aus den gespeicherten Artikellisten gelöscht.

Nun werde ich einige Szenarien beschreiben, gehe auf die Fehlerbehandlung davon ein und würde gern wissen, ob ihr das anders machen würdet und wenn ja, wie und warum? :slight_smile:

Szenario1:

Ein Benutzer A erstellt sich eine Liste von Artikeln, die temporär gehalten wird. Während der Nutzer sich die Artikel aussucht, löscht der Superuser einen Artikel, den der Benutzer A in seiner Liste hat. Nun klickt der Benutzer auf absenden. Da es mindestens ein Artikel nicht mehr gibt, wird nun eine Exception von der Datenbank geworfen.

Szenario2:

Ein Benutzer A erstellt sich eine Liste von Artikeln, die temporär gehalten wird. Während der Nutzer sich die Artikel aussucht, löscht der Superuser einen Artikel, den der Benutzer A in seiner Liste hat. Nun klickt der Benutzer auf speichern. Da es mindestens ein Artikel nicht mehr gibt, wird nun eine Exception von der Datenbank geworfen.

Szenario3:

Ein Benutzer A lädt eine Liste von Artikeln. Während der Nutzer sich die Artikel anschaut, löscht der Superuser einen Artiekl, den der Benutzer A in seiner Liste hat. Nun fügt der Benutzer neue Artikel hinzu und klickt auf speichern. Da es mindestens ein Artikel nicht mehr gibt, wird nun eine Exception von der Datenbank geworfen.

Fehlerbehandlung:
Ich melde dem Benutzer, dass es mindestens einen Artikel nicht mehr gibt und biete ihm an die Liste aktualisieren zu lassen. Das heißt alle Artikel, die es nicht mehr gibt, rauswerfen zu lassen.

Szenario4:

Der Superuser löscht einen Artikel. Benutzer A lädt seine Artikelliste und stellt fest, dass Artikel verschwunden sind.

Fehlerbehandlung:
Hier bin ich mir nicht sicher, ob das wirklich ein tolles Verhalten ist oder ob, wenn ein Artikel gelöscht wird, jeder User, der diesen Artikel in einer Liste gehabt hat, evtl. eine Nachricht bekommen sollte?


Nun würde ich gern wissen, wie ihr solch ein Verhalten implementieren würdet, bzw. wie ihr den Nutzern das mitteilen würdet.

Standardmäßiges Verhalten eines Webshops. Es existiert eine Prüfung vor jedem Speichern, Laden oder absenden einer Artikelliste.
Fehlermeldung ausgeben, dass der Artikel entfernt wurde.

[QUOTE=timbeau]Standardmäßiges Verhalten eines Webshops. Es existiert eine Prüfung vor jedem Speichern, Laden oder absenden einer Artikelliste.
Fehlermeldung ausgeben, dass der Artikel entfernt wurde.[/QUOTE]

schon, nur bin ich mir beim letzten Punkt irgendwie nicht sicher, ob ich eine Nachricht senden oder einfach den Artikel rausnehmen sollte. Was vll. ein ungewöhnliches/unerwartetes Verhalten wäre

[quote=pl4gu33]Es werden also alle Fremdschlüsselreferenzen auf diesen Artikel aus den gespeicherten Artikellisten gelöscht.[/quote]Das Problem hier ist: wie willst Du dem Anwender zu sagen, **welcher **Artikel (aus seiner Liste) entfernt wurde?

Idee: Der Artikel bekommt ein “gelöscht”-Flag. Der Admin setzt dies für den Artikel.
Wenn der Anwender jetzt seine Liste läd oder speichert bekommt er eine Meldung und der Artikel wird danach physisch aus seiner Liste gelöscht.

wenn es keine Listenreferenzen mehr auf den Artikel gibt wird auch dieser aus der Db gelöscht.

bye
TT

Genau, das „welcher“ wäre bei den oben genannten Lösungen von mir ein Problem. Ich würde halt nur die Liste aktualisieren und der User würde nur noch Artikel sehen, die es gibt. Das mit dem Flag ist eine gute Idee, müsste ich halt nur die Tabelle erweitern, was ja kein Problem ist.

[quote=pl4gu33]müsste ich halt nur die Tabelle erweitern[/quote]Wenn Du dann noch die Updates nicht gegen die Tabellen selbst sondern gegen Views machst kannst Du sogar noch ohne Klimmzüge die Listen bereinigen (instead of Trigger ist das Zauberwort) und feststellen ob der Artikel schon löschbar ist…

bye
TT

Damit verlagert man aber Anwendungslogik in die Datenbank. Das kann böse enden.

[quote=cmrudolph]Damit verlagert man aber Anwendungslogik in die Datenbank.[/quote]Guter Punkt.

[quote=cmrudolph;91259]Das kann böse enden.[/quote]Nicht unbedingt, ich habe schon an mehreren Anwendungen mitgearbeitet bei denen die Geschäftslogik komplett in der DB liegt. Das ist keine schlechte Lösung, solange man das konsequent betreibt…

bye
TT

Also ich werde die Logik komplett aus der DB lassen, da Trigger bei uns nicht gern gesehen sind. (Nicht auf meinem Mist gewachsen^^)
Danke für die Tipps :slight_smile:

Ich kann den Standpunkt sehr gut nachvollziehen. Mit Triggern kann man bestimmte Probleme äußerst elegant lösen (vor allem, was Datenbankintegrität angeht).
Der große Nachteil ist aber, dass man die Trigger berücksichtigen muss, wenn die Anwendung weiter entwickelt wird. Da die Trigger in der Entwicklungsumgebung nicht sonderlich exponiert dargestellt werden (falls überhaupt…), kann es schnell passieren, dass man sie vergisst.