Kundennummer generieren?

[AlexII]

Hallo,

ich möchte in meiner DB die Kundennummern generieren und brauche ein paar Ideen wie ich das machen soll.

Ich kann die letzte Ziffer nehmen und 1 addieren, aber was ist wenn ich die letzte lösche, dann wird zu der vorletzten 1 addiert und ich bekomme schon mal vorhandene Kundennummer, somit wird diese wiederholt, was verboten sein soll.

Würde über eure Ratschläge freuen!

[jobo]

Mit autoincrement z.B.
http://sqlite.org/syntaxdiagrams.html#column-constraint

[AlexII]

Zitat:

Zitat von jobo (Beitrag 1203604)

Mit autoincrement z.B.
http://sqlite.org/syntaxdiagrams.html#column-constraint

Autoincrement hat aber genau das Problem was ich beschrieben habe. Löscht man die letzte Zahl, legt neue an, und das wird dasselbe was vorher gelöscht wurde.

[BUG]

Eben nicht. Der Link war irgendwie nicht sehr hilfreich.

Zitat:

If a column has the type INTEGER PRIMARY KEY AUTOINCREMENT then a slightly different ROWID selection algorithm is used. The ROWID chosen for the new row is at least one larger than the largest ROWID that has ever before existed in that same table.

[https://sqlite.org/autoinc.html]

Allerdings würde ich überlegen, das Datenbankdesign so anzupassen, dass zumindest die Nummer (mit Löschungsdatum) eines gelöschten Kunden gespeichert bleibt.
Das erscheint mir robuster.

Also zwei Tabellen:

CUSTOMER(id, created, deleted)
ACTIVE_CUSTOMER(id -> CUSTOMER.id, ...)

[AlexII]

Zitat:

Zitat von BUG (Beitrag 1203611)

Eben nicht. Der Link war irgendwie nicht sehr hilfreich.

Zitat:

If a column has the type INTEGER PRIMARY KEY AUTOINCREMENT then a slightly different ROWID selection algorithm is used. The ROWID chosen for the new row is at least one larger than the largest ROWID that has ever before existed in that same table.

[https://sqlite.org/autonc.html]

Allerdings würde ich überlegen, das Datenbankdesign so anzupassen, dass zumindest die Nummer (mit Löschungsdatum) eines gelöschten Kunden gespeichert bleibt.
Das erscheint mir robuster.

Also zwei Tabellen:

CUSTOMER(id, created, deleted)
ACTIVE_CUSTOMER(id -> CUSTOMER.id, ...)

Hab ich aber getestet und es läuft wie ich gesagt hab. Also jetzt bin ich verwirrt.

[DSCHUCH]

in postgresql gibt es sequenzen, die garantiert nur einmal die gleiche zahl zurückgeben. (eigentl. bereits wegen transaktionssicherheit notwendig)

in sqllite scheint es sowas auch zu geben, mußt du mal googlen.

http://stackoverflow.com/questions/6...ment-in-sqlite

[BUG]

Zitat:

Zitat von AlexII (Beitrag 1203612)

Hab ich aber getestet und es läuft wie ich gesagt hab. Also jetzt bin ich verwirrt.

Also mir funktioniert es:

Code:

$ sqlite3 test.sqlite
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table miep (id INTEGER PRIMARY KEY AUTOINCREMENT, foo INTEGER);
sqlite> insert into miep values (NULL, 1);
sqlite> insert into miep values (NULL, 2);
sqlite> insert into miep values (NULL, 3);
sqlite> delete from miep where foo = 2;
sqlite> insert into miep values (NULL, 4);
sqlite> select * from miep;
1|1
3|3
4|4
sqlite>

Ich kann mir eigentlich kaum vorstellen, dass es am Wrapper liegt.

[Furtbichler]

Na und wenn doch: Eine Tabelle mit einer Zeile und einer Spalte und dort einen streng monoton steigenden Zähler implementieren. Nicht ganz trivial bei multithread, aber kein Problem.

[AlexII]

Zitat:

Zitat von BUG (Beitrag 1203620)

Zitat:

Zitat von AlexII (Beitrag 1203612)

Hab ich aber getestet und es läuft wie ich gesagt hab. Also jetzt bin ich verwirrt.

Also mir funktioniert es:

Code:

$ sqlite3 test.sqlite
SQLite version 3.7.13 2012-06-11 02:05:22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> create table miep (id INTEGER PRIMARY KEY AUTOINCREMENT, foo INTEGER);
sqlite> insert into miep values (NULL, 1);
sqlite> insert into miep values (NULL, 2);
sqlite> insert into miep values (NULL, 3);
sqlite> delete from miep where foo = 2;
sqlite> insert into miep values (NULL, 4);
sqlite> select * from miep;
1|1
3|3
4|4
sqlite>

Ich kann mir eigentlich kaum vorstellen, dass es am Wrapper liegt.

Du hast eine Zahl irgendwo mittendrin gelöscht, da funkt alles wie es sein soll. Aber lösche mal die letzte Zahl, also die 3 und füge eine neue hinzu, und das wird wieder die 3 sein. Zumindest bei mir so.

[khh]

Zitat:

Zitat von AlexII (Beitrag 1203597)

Hallo,

ich möchte in meiner DB die Kundennummern generieren und brauche ein paar Ideen wie ich das machen soll.

Ich kann die letzte Ziffer nehmen und 1 addieren, aber was ist wenn ich die letzte lösche, d

Ist doch ganz einfach, wie schon geschrieben, increment.
Bereits genutzte Kundennummern löscht man nicht.
Somit werden doppelte Vergaben vermieden.
Nenne mir einen Grund, weshalb du bereits vergebene Nummern wieder löschen willst?

[AlexII]

Aber dann habe ich Karteileichen, wozu brauche ich die?

[mkinzler]

Z.B. Historie, Nachweis, ...

[AlexII]

Ok, ist ein wichtiger Grund. Aber mir geht's jetzt um's Prinzip, wie kann ich vermeiden, dass ne Zahl wiederholt vergeben wird...

[khh]

Zitat:

Zitat von AlexII (Beitrag 1203675)

Ok, ist ein wichtiger Grund. Aber mir geht's jetzt um's Prinzip, wie kann ich vermeiden, dass ne Zahl wiederholt vergeben wird...

Lass die Nummern durch einen DB-Trigger generieren.

[AlexII]

Zitat:

Zitat von khh (Beitrag 1203678)

Zitat:

Zitat von AlexII (Beitrag 1203675)

Ok, ist ein wichtiger Grund. Aber mir geht's jetzt um's Prinzip, wie kann ich vermeiden, dass ne Zahl wiederholt vergeben wird...

Lass die Nummern durch einen DB-Trigger generieren.

Hm... kannst du das vielleicht näher erläutern? Was ist ein DB-Trigger?

[khh]

http://de.wikipedia.org/wiki/Datenbanktrigger

[mkinzler]

Zitat:

Zitat von AlexII (Beitrag 1203675)

Ok, ist ein wichtiger Grund. Aber mir geht's jetzt um's Prinzip, wie kann ich vermeiden, dass ne Zahl wiederholt vergeben wird...

Wie schon geschrieben autoincrement. wenn du keinen Kunden löschst, gibt es auch keine doppelte Vergabe.

Zitat:

Hm... kannst du das vielleicht näher erläutern? Was ist ein DB-Trigger?

Eine Funktionalität einiger DBMS, bei denen dann eine Funktion aufgerufen wird, wenn ein bestimmtes Ereignis ( Neuer Datensatz, Änderung/Löschung eines Datensatzes) ausgelöst ("getriggert") wird.

[AlexII]

Kennt die SQLite überhaupt die Trigger?

[Klaus01]

Zitat:

Zitat von AlexII (Beitrag 1203689)

Kennt die SQLite überhaupt die Trigger?

siehe hier

Grüße
Klaus

[khh]

http://www.sqlite.org/lang_createtrigger.html

doppelt hält besser :-)

[AlexII]

Danke für eure Posts :thumb:

Kann mir vllt jemand ein gutes SQLite-Buch < 20€ empfehlen?

[mjustin]

Zitat:

Zitat von AlexII (Beitrag 1203675)

Ok, ist ein wichtiger Grund. Aber mir geht's jetzt um's Prinzip, wie kann ich vermeiden, dass ne Zahl wiederholt vergeben wird...

Wenn die Zahl als Primärschlüssel einer Tabelle verwendet wird, ist Wiederholung nicht möglich, ein Primärschlüssel ist in der Regel durch eine "Unique Constraint" (eindeutiger Index) abgesichert.

[AlexII]

Zitat:

Zitat von mjustin (Beitrag 1203695)

Zitat:

Zitat von AlexII (Beitrag 1203675)

Ok, ist ein wichtiger Grund. Aber mir geht's jetzt um's Prinzip, wie kann ich vermeiden, dass ne Zahl wiederholt vergeben wird...

Wenn die Zahl als Primärschlüssel einer Tabelle verwendet wird, ist Wiederholung nicht möglich, ein Primärschlüssel ist in der Regel durch eine "Unique Constraint" (eindeutiger Index) abgesichert.

Hast recht, aber wenn du den letzten Schlüssel löschst und nen neuen einfügst, wird dieser genau das sein, was du vorher gelöscht hast.

[khh]

Zitat:

Zitat von AlexII (Beitrag 1203696)

Hast recht, aber wenn du den letzten Schlüssel löschst und nen neuen einfügst, wird dieser genau das sein, was du vorher gelöscht hast.

nein, nicht wenn du das per DB-Trigger machst.

Trotzdem nochmal:
Kundennummern löscht man nicht, Primärschlüssel erst recht nicht!

[Klaus01]

nur mal ein Gedankenspiel...

Du hast einen Kundennummernkreis 1000-1999.
Hieraus vergibst Du Kundennummern.
Sollte ein Kunde nicht mehr Dein Kunde sein wollen - kannst Du die entsprechende Kundennummer mit einem "to delete" Flag versehen.

Ist dann die Kundennummer 1999 erreicht.
Fängt ein neuer Kundennummernkreis an (2000-2999).
Aud dem alten Kundennummernkreism kannst Du nun die Kundennummern die mit dem "to delete" Flag versehen sind löschen.
Neue Kundennummern werden nur noch aus dem neuen Kundennummernkreis vergeben.

Grüße
Klaus

[sx2008]

Also es gibt verschiedene Verfahren, um Kundennummern bzw. andere Zähler zu generieren.

1.) Autoincrement-Felder
Davon würde ich abraten. Das Problem ist, dass die Nummer dann zwar im Feld steht, aber die Anwendung bekommt die Nummer nicht zurück; weiss also nicht welche Kundennummer gerade neu vergeben wurde.
Es gibt zwar Möglichkeiten, die letzte Autoincrement-Nr zurück zu erhalten (INSERT INTO x RETURNING y) aber das ist nicht standardisiert und beherrscht nicht jede Datenbank.

2.) Generatoren
Ein Generator liefert immer ein garantiert eindeutige Nummer zurück (auch im Multiuserbetrieb).
Man fragt also einen Generator mit einem best. Namen ab und bekommt so eine eindeutige Nummer.
Das Verfahren ist technisch sauber aber leider haben nicht alle Datenbanken Generatoren.

3.) Maxwert + 1
Man holt sich die höchste Nummer + 1 mit

SQL-Code:

SELECT (MAX(Kundennr)+1) AS NewKundennr FROM Tabelle

Problem: beim Muliuserbetrieb kann es zu Kollisionen kommen, weil 2 Clients die gleiche Nummer gezogen haben
Sehr einfaches Verfahren - empfehlenswert, bei wenig konkurierenden Zugriff
Bei einer Kollision; also es gibt schon einen Datensatz mit der Nummer muss der Client einfach nochmal den Maxwert +1 holen. (nach 20 Fehlversuchen Fehlermeldung ausgeben)

4.) Reservierung über eigene Tabelle
In einer speziellen Tabelle wird die nächste freie Nummer gespeichert
Die Zugriffe Lesen - Nummer erhöhen und zurückschreiben müssen über Transaktionen abgesichert werden
Im Prinzip kann man so fehlende Generatoren nachbilden

5.) Mehrfach - Reservierung über eigene Tabelle
wie 4.) nur dann ganze Blöcke reserviert werden.
Ein Client kann sich z.B. die Werte 500 bis 531 reservieren.
Damit muss er erst wieder neue Werte reservieren wenn die 32 Zahlen verbraucht sind.

6.) out-of Band Kommunikation
Auf dem Server läuft zusätzlich noch ein Dienst, über den die Clients ihre Nummern ziehen können ohne dass es zur doppelten Vergaben kommen kann.
Dieser Dienst wird z.B. über TCP/IP oder Named Pipes angesprochen.
Im Prinzip werden Generatoren ausserhalb der Datenbank nachgebildet.
Nachteil: sehr aufwändig

7.) Random Werte
Der Client zieht ein Zufallszahl und schaut nach ob es dazu schon einen Datensatz gibt
Vorteil: sehr einfach zu implementieren
Nachteile: Nummer werden zufällig und nicht aufsteigend vergeben,
bei zunehmendem Füllungsgrad der Tabelle muss der Client immer öfters feststellen, dass seine Zufallszahl schon vergeben ist und erneut eine neue Zufallszahl testen.
Im Extremfall ist der Client dauerhaft blockiert

[p80286]

Zitat:

Zitat von khh (Beitrag 1203699)

Trotzdem nochmal:
Kundennummern löscht man nicht, Primärschlüssel erst recht nicht!

Pack einen Löschvermerk dahinter, nimm ein Endedatum oder sonst irgendwas, aber nicht löschen!
(was meint Ihr wohl wieviele Doppelbelegungen es bei einer 6Stelligen Personalnummer gibt, wenn nach 6 Jahren diese Nummer wieder vergeben wird? durchschn. 7000 Personen) nach 10 Jahren ca. 250.

Jetzt hat sie 8 Stellen und wird nur einmal vergeben.

Gruß
K-H

[AlexII]

@sx2008 thx... :thumb:

[Der.Kaktus]

Zitat:

Zitat von p80286 (Beitrag 1203733)

Zitat:

Zitat von khh (Beitrag 1203699)

Trotzdem nochmal:
Kundennummern löscht man nicht, Primärschlüssel erst recht nicht!

Pack einen Löschvermerk dahinter, nimm ein Endedatum oder sonst irgendwas, aber nicht löschen!
(was meint Ihr wohl wieviele Doppelbelegungen es bei einer 6Stelligen Personalnummer gibt, wenn nach 6 Jahren diese Nummer wieder vergeben wird? durchschn. 7000 Personen) nach 10 Jahren ca. 250.

Jetzt hat sie 8 Stellen und wird nur einmal vergeben.

Gruß
K-H

So, sollte man es machen :-D

[Morphie]

Also wir erlauben auch das Löschen von Kunden. Natürlich macht das auf dem ersten Blick wenig Sinn, doch aus 20+ Jahren Erfahrungen kommt irgendwann ein Anwender an und möchte einen Kunden tatsächlich löschen. Warum er es möchte, ist nicht unbedingt wichtig, doch um mal ein paar Gründe zu nennen:
- DAU-Bedingte Falschbedienung. Der Anwender klickt einfach zig mal auf "Neuen Kunden anlegen" und "abspeichern".
Hier wäre es natürlich möglich, die gleichen Kundennummern für Produktivdatensätze zu verwenden. Also ein "Kunden bearbeiten" > Daten eintragen > "Speichern", doch viele Anwender denken da nicht so weit und klicken lieber direkt ein weiteres Mal auf "Neuen Kunden anlegen".
- Expliziter Wunsch des Kunden, alle Daten aus dem System zu löschen
Meiner Meinung Nach sollte das in Zeiten von Datenschutzskandalen möglich sein.
- Zusammenfassung mehrerer Kunden
- Testdatensätze
...

Damit eine KundenNr nicht 2x vorkommt, würde ich eine Sequenz verwenden. Alternativ kann man auch eine weitere Tabelle nehmen, und diese als Zähler verwenden.
Der Vorteil einer weiteren Tabelle wäre, dass man die KundenNr auch Alphanumerisch hochzählen kann, bzw. dort x-beliebige Logik verwenden kann.
Die Vergabe der KundenNr gehört natürlich in einen Trigger.

[EgonHugeist]

@Morphi

Wir benutzen buchhalterisch auch elektronische Daten für's Finanzamt. Aus Gründen der Nachvollziehbarkeit würde ich in JEDEM FALL vom Löschen der Kundennummern abraten. Schon mal 'ne Tiefenprüfung mitgemacht? Die Löschung der Kundendaten sollte mit dem NULLen aller persönlicher Daten getan sein. Willst du jedoch später Rechungen etc. welche Beleghaft gebucht wurden einem Kunden X zuordenen wird es echt unmöglich dem Folge zu leisten. Keine Buchung ohne Beleg, im Zweifelsfall für den Staat -> private Buchung -> Einkommenssteuer???. Alle Belege electronischer Art sollten mit Hilfe eines Backups nachvollziehbar bleiben UND die Kundendaten gelöscht werden... Ich würde mich allen Vorrednern anschließen, dass man den Kundenschlüssel selber, ob genutzt oder nicht, NIE löscht.

Btw. Trigger und Sequenzen/Generatoren mit SQLite? Wie?

[khh]

Zitat:

Zitat von EgonHugeist (Beitrag 1203776)

@Morphi

Daten für's Finanzamt.

ein ZWINGENDER Grund keine Kundendaten zu löschen!

[EgonHugeist]

Zitat:

Zitat von khh (Beitrag 1203797)

ein ZWINGENDER Grund keine Kundendaten zu löschen!

Ja/Nein. Wir sind verpflichtet die Kundendaten zu Löschen(NULLen), wenn es der Kunde wünscht. Jeder ist dazu gesetzlich verpflichtet. Alle Belege werden als PDF generiert und mit einem komulativen Backup gesichert. Buchhalterische Ordnung und Nachvollziehbarkeit. Sollte eine Prüfung seitens FA durchgeführt werden, kann man die gesichten Belege den Aufträgen und den damit verbunden Positionen, mit Hilfe des Kundenschlüssels, zugeordnet werden. Also Löschen aller persönlicher Daten JA jedoch alle interne Vorgänge, welche mit dem Kundenschlüssel verbunden sind NEIN. Sind wir uns einig?

[Sir Rufo]

Zitat:

Zitat von EgonHugeist (Beitrag 1203798)

Zitat:

Zitat von khh (Beitrag 1203797)

ein ZWINGENDER Grund keine Kundendaten zu löschen!

Ja/Nein. Wir sind verpflichtet die Kundendaten zu Löschen(NULLen), wenn es der Kunde wünscht. Jeder ist dazu gesetzlich verpflichtet. Alle Belege werden als PDF generiert und mit einem komulativen Backup gesichert. Buchhalterische Ordnung und Nachvollziehbarkeit. Sollte eine Prüfung seitens FA durchgeführt werden, kann man die gesichten Belege den Aufträgen und den damit verbunden Positionen, mit Hilfe des Kundenschlüssels, zugeordnet werden. Also Löschen aller persönlicher Daten JA jedoch alle interne Vorgänge, welche mit dem Kundenschlüssel verbunden sind NEIN. Sind wir uns einig?

Zum Thema Verpflichtung kann man auch mit Ja und Nein antworten

http://dejure.org/gesetze/BDSG/35.html

Man kann es pauschal nicht beantworten, denn es ist abhängig von mehreren Faktoren u.a. auch von der Art der Unternehmung

[AlexII]

Leute das Thema ist eine andere, es geht um die Generierung der Kundennummer. :wink:

[Sir Rufo]

Um auf das eigentliche Thema zurückzukommen:

In einer Software hat man zumeist mehrere Nummernkreise, die es zu verwalten gilt und die auch nicht doppelt vergeben werden dürfen:

Kundennummer, Rechnungsnummer, Artikelnummer, etc.

Oft gesehen und auch selber so eingesetzt ist eine Tabelle LetzteNummern mit den Feldern Bereich und Nummer (evtl. noch Inkrementwert und diversen Kennzeichen für weitere Spezialitäten dieses Nummernkreises).

Auf einmal kann man auch flexibel auf Kundenwünsche eingehen (sofern diese sich rechtlich vereinbaren lassen, logisch)

Zitat:

Zitat von AlexII (Beitrag 1203811)

Leute das Thema ist eine andere, es geht um die Generierung der Kundennummer. :wink:

Immer ruhig :wink: ich bin schon älter und brauche Zeit zum Tippen ;)