Nummernzäler für Verkaufsvorgänge - Tabelle sperren und warten,...

[WiglWagl76]

Hallo,

ich soll eine kleine Anwendung schreiben, in der Verkaufsvorgänge erfasst werden. Es gibt hier verschiedene Gruppe (Angebot, Auftrag, Lieferschein, Rechnung,...). Jede Gruppe bekommt
per Definition einen Nummernzähler, welcher in einer Tabelle definiert wird, ca so.


Vorgang Zählerstand Obergrenze Untergrenze

Rechnung 300010 309000 300000
Angebot 100115 109000 100000
Auftrag 200540 209000 200000
...

Wenn nun ein Angebot gespeichert wird, soll die nächste Nummer, hier 100115 + 1 gezogen werden. Problem an der Sache ist, was passiert, wenn zwei oder mehr User zur selben Zeit ein
Angebot speichern. Wie verhält es sich mit der Tabelle, wo die Nummernkreise gespeichert sind? Kann man hier eine Art Lock oder Wartezustand erzeugen? Wie würdet Ihr hier vorgehen?

Vielen Dank
lg
WW

[defo]

Du musst eine atomare Operation bauen / verwenden, die den Wert abfragt, zurückgibt, addiert und wegschreibt.
Sperren würde ich da gar nichts, damit erhöhst Du nur die Wahrscheinlichkeit, dass man sich gegenseitig auf den Füßen steht.

Datenbankspezifisch kann man da sicher mehr zu sagen. Es gibt bspw. Sequenzen oder Autoincrement felder, die den Großteil Deiner Probleme lösen.

[WiglWagl76]

Servus,

verzeih meine Unwissenheit, was sind atomare Operationen? Ich habe mal versucht mittels Google schlauer zu werden, aber irgendwie erschließt sich da bei mir nichts.
Wichtig ist im Grunde nur, dass den Zählerstand, den User A bekommt, nicht der ist, den User B bekommt. Autoincrement Felder sind hier nicht wirklich praktikabel, da
der Nummernkreis recht variabel ist und z.b. auch ein Prefix haben kann und am Ende eine Nummer wie AU13.200541 heraus kommen kann.
Meinst Du kann man mit Transaction auch zum Erfolg kommen?

Danke aber mal für die Stichwörter....

lg
ww

[defo]

Atomar ist wahrscheinlich auch gar nicht der treffende Begriff, sorry.
Gemeint ist eine Operation (im Sinne Transaction), die Abfragt, hochzählt und zurückschreibt.
Eine Transaction ist es von allein, sollange Du nicht explizit zurückrollst oder commitest.
Solch ein Vorgang (Transaction) kann per se nicht von anderen Sessions unterbrochen werden.

Wenn Du im client die 3 Schritte mit separaten Queries durchführst, ist es erstmal keine gemeinsame Transaction mehr.
Wenn unterstützt durch das RDBMS bietet sich eine Server Funktion an, die alles auf einmal erledigt.

[fanderlf]

Jede Datenbank hat üblicherweise einen Mechanismus um automatisch hochzählende Nummern zu generieren (Sequenz + Trigger in Oracle, MS SQL glaub hat sowas wie auto inc Felder...). Wenn Du nicht unbedingt Nummern ohne Lücken brauchst, das wird ja bei Rechnungssystem oftmals gefordert, dann würde ich auf jeden Fall zu diesem Mittel greifen. Alles andere ist trivial nicht lösbar und durchaus ein komplexes Problem.

[Ralf Jansen]

Wie man das löst hängt ein wenig davon ab ob der Nummernkreis lückenlos ausgenutzt werden muß. Darf der Nummernkreis lücken aufweisen (dann wäre es relativ einfach)?

[defo]

Jede Datenbank hat üblicherweise einen Mechanismus um automatisch hochzählende Nummern zu generieren ...

Auto Inc und auch der simple Einsatz von Sequenzen fällt laut TE raus.
Hier geht es offenbar darum, eine Sequenz mit Formatmaske oder so ähnlich selbst zu entwickeln.

Lückenlosigkeit war nicht verlangt. Ist aber m.E. ein nachgelagertes (fachliches) Problem und kommt erst zum Tragen, wenn man überhaupt sauber die gewünschten Sequenz-Bänder produzieren kann.

[tömmel]

1.) Ich soll zuhause die Fassade dämmen. Hab ich gesagt : Kann ich nicht, holt ne Firma...
2.) Kommt aufs DBMS an aber so ziemlich überall kann man eine prozedur basteln, die das erledigt .. beispiel next_id(Typ) und gibt dann den richtigen Wert zurück... ansonsten siehe 1.)

[Ralf Jansen]

Lückenlosigkeit war nicht verlangt.

Aber eventuell trotzdem nötig. Es gibt Steuerprüfer die dumme Fragen stellen wenn man eine Rechnung 3 und 5 hat aber keine 4.

2.) Kommt aufs DBMS an aber so ziemlich überall kann man eine prozedur basteln, die das erledigt

Und wenn man das naiv angeht kommt man nachher zu einer Lösung die den Datenbankzugriff vollständig serialisiert. Ab einer bestimmten Anzahl von Nummern/Sekunde wird es relevant wie man das löst.

[tömmel]

Aber eventuell trotzdem nötig. Es gibt Steuerprüfer die dumme Fragen stellen wenn man eine Rechnung 3 und 5 hat aber keine 4.



Und wenn man das naiv angeht kommt man nachher zu einer Lösung die den Datenbankzugriff vollständig serialisiert. Ab einer bestimmten Anzahl von Nummern/Sekunde wird es relevant wie man das löst.

Bei der Rechnung ist das ja auch gefordert(!)- wenn man das naiv angeht gibt das garantiert Stress (wie immer im Leben) .
Ich hab wohl schon mehr Aufträge/Anliegen in diversen Bereichen rundum abgelehnt, weil ich da keine Erfahrung habe und nicht einschätzen kann, ob oder wie ich das sicher zum Ende bringe.
Daher der Punkt 1.) Nicht nur weil ich ein frustrierter alter Mann bin^^, sondern weil eben Tränen fließen, wenn etwas nicht zu Potte kommt oder am Ende nicht funktioniert obwohl Zeit und Geld hineingeflossen sind...

Der TE steht mit der Aufgabe wohl noch am Anfang - ein guter Zeitpunkt noch eine Entscheidung zu treffen, bevor immer neue 'unüberwindliche' Hindernisse auftauchen..(uups, da fehlen ja ne Nummer in den Rechnungen /Gutschriften...)