Überschneidung bei DB-Eintrag

[Honny]

Also, habe einen Online-Shop mit 10 Stück einer Ware XY:
User A kommt auf Bestellformular und will 10 Stück o. g. Ware bestellen (Mit dem Aufrufen des Bestellformulars wurde natürlich schon die aktuell verfügbare Menge in der DB abgefragt.). Bevor User A das Bestellformular abschickt, trödelt er auf der Seite noch so ein bisschen rum.
Inzwischen ist User B auf das Bestellformular gelangt und bestellt ohne Verzögerung 10 Stück. Theoretisch könnte jetzt User A durch Absenden seines Formulars auch noch mal 10 Stück bestellen, obwohl eigentlich kein Bestand mehr verfügbar ist.
Wie läßt sich ein solches Dilemma vom theoretischen Ansatz her am einfachsten vermeiden ???
Wie wird so was in der Praxis normalerweise gemacht ???

[goth]

Indem du die Artikel im Warenkorb als reserviert berücksichtigst ... !

[Abraxax]

sprich.... vor den tatsächlichen reservieren muss du noch einmal prüfen, ob die menge noch vorhanden ist.

user a ist selber schuld, wenn er trödelt...

[Honny]

Wie hab' ich das "Reservieren zu verstehen ???

[Innuendo]

Das hast Du so zu verstehen, dass Du eine Spalte hast, die z.B. "reserviert" heißt. Bestellt User A 10 Stück, dann schreibst Du in diese Spalte "10" rein, d.h. dass 10 Stück sozusagen "vorbestellt" sind.

[Honny]

Aber wenn User A auf dem Bestellformular ist, weiß ich ja noch garnicht, wieviel er letztendlich bestellen wird. Das sehe ich ja erst, wenn er das Formular abgesandt hat, sprich wenn die Bestellung in der DB verbucht ist.
Und ich kann ja schlecht von vorneherein den gesamten Bestand reservieren (blockieren), weil er ja evtl. z. B. nur 5 Stück nimmt.

[wahsaga]

wer zuerst kommt, mahlt zuerst.

wenn user A ewig rumtrödelt, user B ihm also in der zwsichenzeit die zehn artikel weggeschnappt hat, dann bekommt user A eben nach dem absenden seines formulares die meldung angezeigt, dass es keine 10 stück mehr gibt.

ich sehe nicht, wo da das problem liegt ...

[Honny]

@wahsaga: Ah, da kommen wir der Sache ja schon näher. Ich vermute jetzt mal, du meinst, man müsste vor dem DB-Eintrag noch mal checken, ob wirklich immer noch Bestand da ist.
Das scheint ja für Euch alles selbstverständlich zu sein. Ich wollte halt eben möglichst wenige DB-Anfragen generieren und konnte mir zudem nicht vorstellen, daß die Lösung so trivial sein sollte.

wer zuerst kommt, mahlt zuerst

^^Das ist ja prinzipiell richtig; nur wenn das Ganze nicht richtig durchdacht ist, ist der Verkäufer der Dumme, wenn er nicht liefern kann (Denn es ist ja seine Schuld, wenn er eine Bestellung zulässt, obwohl er eigentlich keinen Bestand mehr hat.).

[goth]

Wann willst Du denn so etwas prüfen ... ?

Natürlich wird so etwas geprüft wenn das Formular abgeschickt wird ...

Normalerweise hat man irgendwo in der DB einen Bestand stehen ... und zieht davon die vorliegenden Bestellungen ... und die Bestände vorliegender Warenkörbe ab ... man sollte dabei halt zusehen das ein nicht in eine Bestellung umgewandelter Warenkorb nicht zu lange bestehen bleibt ...

... zuviele DB-Abfragen mag nicht gut sein ... zu wenige ist aber auch nicht besser ...
... Benutzereingaben werden immer im empfangenden Script geprüft ... Prinzip: "Never trust incomming Data!".

[Honny]

@goth: Schon klar ! In meinem Fall möchte ich halt im Formular selbst die noch zur Verfügung stehende Menge anzeigen. Infolgedessen muß ich auch schon vor Formularausgabe eine Bestandsabfrage machen.

[Innuendo]

Jein.

1. Möglichkeit: Du zeigst vor dem Formular dem Nutzer an, wieviel noch im Bestand ist. Dann weiß er, wieviele er noch bestellen kann.

2. Möglichkeit: Der Nutzer füllt das Formular aus und klickt auf "Übernehmen". Jetzt überprüfst Du anhand der eingegebenen Bestellmenge, ob soviele Stücke überhaupt noch verfügbar sind.

[Honny]

Hab 's inzwischen gemäß der 2. Möglichkeit von Innuendo umgesetzt.
Ich glaube, das reicht für meine Zwecke.

Danke noch mal !