SQLdb, Firebird und auto_increment

[charlytango]

Der Anwender darf sich halt nicht vertun.

Das ist für mich ein klarer Hinweis, dass der Geschäftsfall nicht sauber definiert/designed ist.
Nummernvergaben versuche ich so zu designen dass der Anwender/Benutzer möglichst wenig damit zu tun hat. Denn er wird sich langfristig SICHER "vertun".
Eine Software hat IMHO die Aufgabe solche Geschäftsfälle sicher und fehlerlos zu machen.

Ich kenne den Ablauf von Auktionen zuwenig um das Vorschläge machen zu können.
Aber was ich herausgelesen habe ist, dass es Auktionen gibt an denen Objekte versteigert werden.
Für mich schonmal drei Tabellen.
zb TAuktion (auktID, Datum, Ort, etc etc) und TObjekt(objektID, Beschreibung, etc etc) und TAuktionObjekt(auktobjektID, objektID, auktID, ObjektNummer, verkauft_janein, Verkaufspreis, etc etc)

Damit können Objektdaten erfasst werden und deren Zuordnung zu einer Auktion ist flexibel.

Nur für die Objektnummernvergabe würde ich pro Auktion je eine eigene Tabelle erstellen welche nur die eine nummerID hat. Diese Tabelle kann nach der Aution mit einer Administrationsfunktion in einem Aufräumverfahren wieder gelöscht werden.

Bei der Vergabe der Nummer wird ein neuer Datensatz angelegt und der vergebene Wert/ID aus der DB abgeholt. Soweit ich weiß sind unter MySQL, MariaDB und MSSQL die autoincrement-Funktionen sessionsicher (dh es wird sauber hochgezählt auch wenn mehrere Benutzer mehr oder weniger gleichzeitig daran arbeiten und jeder Benutzer bekommt nur die Nummer zurück die er eingetragen hat. wie Postgres das regelt weiß ich nicht)

Die zurückgegebene/ermittelte Nummer würde ich mit einer modulo division (Restwertdivision) mit einem im Programm hinterlegten Wert dividieren (in deinem Fall ist das die Anzahl der voraussichtlich zur Versteigerung kommenden Objekte -- das ist wohl deine Zahl 200). Der errechnete Wert ist die vergebene Objektnummer.

Das Problem mit den übrig gebleibenen Objekten würde ich als Administrationsfunktion lösen. Alle übrig gebliebenen Objekte können damit dann einer oder mehreren künftigen Auktionen zugeordnet werden. Das Programm macht dann die Einträge automatisch indem es neue Datensätze in TAuktionObjekt für die jeweilige Auktion samt den Nummern erzeugt.

So kannst du auch historisch sagen wie oft ein Objekt schon dran war etc.

Als Adminfunktion braucht es noch Funktionen die einzelne, nicht mehr benötigte Auktionen aus dem System löschen, aber das ist dann eine Frage der Businesslogik, denn vielleicht braucht man die Daten (ggfs auch die Verkaufspreise etc) auch für Auswertungen oder Steuer/Finanzamtsmeldungen.

Das führt doch nur zu Fehlern im Ablauf. Besser ALLE alten Nummern runter und ALLES neu bekleben. Das verstehen auch die Helfer, die nicht immer dabei sind.

Für Objektetiketten würde ich dieser Erfahrungsempfehlung folgen und auch Datum der Auktion, Objektnummer und zumindest eine kurzbeschreibung des Objektes drauf drucken. Farbige Etiketten je Auktion sind sicher auch kein Fehler.

... nur so mal als grobes Design für dein Problem

[Joh]

Also ich kann dazu nur sagen:

Code: Alles auswählen

i) tabAuktion
id
datum
Bez - z.B. Frühjahrsauktion 24
...

ii) tabAuktionsObjekt
id
auktionID
lfdNr - z.B. von 1 bis 80; die Nummer, um die es hier geht
Titel
Bez
Schätzpreis
vkPreis
Bieter
...

und dann die Positionen kopieren.
In der Sommerauktion verkauft man die Reste der Frühjahrsauktion; ändert dabei aber i) den Preis, ii) die Beschreibung und iii) die zugeordneten Bilder
Dabei dürfen die Daten der alten Auktion nicht mehr verändert werden.
Es mag zwar theoretisch schöner/eleganter klingen, aber praktisch lebt man in dem Fall besser mit Duplikaten.

[ErnstVolker]

Vielen Dank für die Vorschläge!
Ich habe es voerst anders gelöst. Ich gebe in der ComboBox die nächste zu verwendende Nummer vor.

[charlytango]

Ich gebe in der ComboBox die nächste zu verwendende Nummer vor.

und woher nimmst du die ?

[ErnstVolker]

Ich schaue in der Überersicht mit "Max" nach.
Andere Variante ist, dass ich beim Vorbereiten der Neuanlage die Box nicht leere und den letzen Wert stehen lasse. Dann muß man nur eins dazuzählen. Die Anzahl der Anwender (nicht mehr wie drei) ist somit überschau- und konditionierbar. Ich werde zunächst mal versuchen sie zu sensibilisieren. Ansonsten erzeuge ich händisch mal eben etwa 80 Datensätze und das Befüllen geht dann mit Update anstelle Insert.
Es gibt Schaltflächen für "Insert" und "Update". Kann ja sein am Datensatz ändert sich was.

[charlytango]

Die Anzahl der Anwender (nicht mehr wie drei) ist somit überschau- und konditionierbar

Der Job eines Entwicklers/Programmierers ist es nicht irgendwelche Anwender (egal welcher Anzahl) zu konditionieren.
Was meiner Erfahrung nach ohnedies nicht klappt.
Sondern so zu entwickeln dass Fehler (zB bei der Nummernvergabe - also einer Kernaufgabe von Programmen) gar nicht erst entstehen. Deine Methode ist IMHO nicht 100% sicher und es kann zu Doppelvergaben kommen.

Da kannst du auch eine gedruckte Nummernliste auslegen die bei jeder Eingabe abgestrichen werden.

[Joh]

Da kannst du auch eine gedruckte Nummernliste auslegen die bei jeder Eingabe abgestrichen werden.

besser noch: eine gedruckte Liste mit Aufklebern drucken, die abgezogen und aufgeklebt werden. => Fehlerminimierung durch fehlendes Abstreichen. Und wenn ein Aufkleber fehlt: egal; shit happens.

[af0815]

+1
Absolut saubere analoge Lösung