SQLdb, Firebird und auto_increment

Für Themen zu Datenbanken und Zugriff auf diese. Auch für Datenbankkomponenten.
charlytango
Beiträge: 813
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz 2.2.6
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: SQLdb, Firebird und auto_increment

Beitrag von charlytango »

ErnstVolker hat geschrieben:
Mo 20. Nov 2023, 07:48
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.
Joh hat geschrieben:
Mo 20. Nov 2023, 08:54
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
Lazarusforum e. V.
Beiträge: 131
Registriert: Sa 26. Mai 2012, 17:31
OS, Lazarus, FPC: Win 10 (L 2.2.6 x64 FPC 3.2.2)
CPU-Target: 64Bit

Re: SQLdb, Firebird und auto_increment

Beitrag von 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.
just my two Beer

ErnstVolker
Beiträge: 318
Registriert: Di 17. Feb 2009, 10:44
OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
CPU-Target: xxBit

Re: SQLdb, Firebird und auto_increment

Beitrag von 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
Beiträge: 813
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz 2.2.6
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: SQLdb, Firebird und auto_increment

Beitrag von charlytango »

ErnstVolker hat geschrieben:
Di 21. Nov 2023, 18:18
Ich gebe in der ComboBox die nächste zu verwendende Nummer vor.
und woher nimmst du die ?

ErnstVolker
Beiträge: 318
Registriert: Di 17. Feb 2009, 10:44
OS, Lazarus, FPC: Winux (L 0.9.xy FPC 2.2.z)
CPU-Target: xxBit

Re: SQLdb, Firebird und auto_increment

Beitrag von 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
Beiträge: 813
Registriert: Sa 12. Sep 2015, 12:10
OS, Lazarus, FPC: Laz 2.2.6
CPU-Target: Win 32/64, Linux64
Wohnort: Wien

Re: SQLdb, Firebird und auto_increment

Beitrag von charlytango »

ErnstVolker hat geschrieben:
Do 23. Nov 2023, 16:25
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
Lazarusforum e. V.
Beiträge: 131
Registriert: Sa 26. Mai 2012, 17:31
OS, Lazarus, FPC: Win 10 (L 2.2.6 x64 FPC 3.2.2)
CPU-Target: 64Bit

Re: SQLdb, Firebird und auto_increment

Beitrag von Joh »

charlytango hat geschrieben:
Fr 1. Dez 2023, 11:47
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.
just my two Beer

Benutzeravatar
af0815
Lazarusforum e. V.
Beiträge: 6118
Registriert: So 7. Jan 2007, 10:20
OS, Lazarus, FPC: FPC fixes Lazarus fixes per fpcupdeluxe (win,linux,raspi)
CPU-Target: 32Bit (64Bit)
Wohnort: Burgenland
Kontaktdaten:

Re: SQLdb, Firebird und auto_increment

Beitrag von af0815 »

+1
Absolut saubere analoge Lösung :lol:
Blöd kann man ruhig sein, nur zu Helfen muss man sich wissen (oder nachsehen in LazInfos/LazSnippets).

Antworten