Kundennummern

[StorageWars]

Guten Tag allerseits,

ich befasse mich schon eine Weile mit Datenbanken und habe auch schon häufiger Kundennummern eingebaut, indem ich einfach den Primärschlüssel einer geeigneten Tabelle verwendet habe.
Jetzt ist es aber so, dass die Kundennummern nicht mit 0001 beginnen sollen, sondern eher pseudo-zufällig wie 1425, 1426, 1427, ...
Weiterhin sollen die Kundennummern eine konstante Länge haben (die 4 Stellen sind nur ein Beispiel) und eventuell ein K wie Kundennummer als Präfix bekommen.
Hier frage ich mich, wie man das am sinnvollsten in einer Datenbank einbaut? Man könnte theoretisch alles in einer Spalte speichern ("K1425"), oder eine 1 Byte Extra-Spalte für den Buchstaben verwenden. Oder man speichert nur die Zahlen als Int und ergänzt den Rest in der Anwendung? Das Präfix war bei einem allgemeinen Suchfeld für effizientere Abfragen gedacht, damit bereits bei der Eingabe von K1... eben keine Telefonnummern, Namensfelder oder ähnliches durchsucht werden. Allerdings könnte man das auch in der Anwendung lösen, aber da fehlt mir die Erfahrung was sinnvoller ist.

Die verwendete Datenbank ist eine aktuelle MariaDB.

Ich danke allen fürs Lesen wünsche noch einen schönen Tag.
StorageWars

[tomBuilder]

Moin auch dir.
möglicherweise ergäntzt du den eingangspost noch ?

[StorageWars]

Hallo tomBuilder,
ja, sorry, ich habe es beim Eingeben des Textes irgendwie geschafft mit der Enter-Taste den Beitrag zu früh abzusenden.

[lstegelitz]

Jetzt ist es aber so, dass die Kundennummern nicht mit 0001 beginnen sollen, sondern eher pseudo-zufällig wie 1425, 1426, 1427, ...
Weiterhin sollen die Kundennummern eine konstante Länge haben (die 4 Stellen sind nur ein Beispiel) und eventuell ein K wie Kundennummer als Präfix bekommen.
Hier frage ich mich, wie man das am sinnvollsten in einer Datenbank einbaut?

In der Datenbank ist das nur noch ein VARCHAR mit einem UNIQUE Index. Was da genau reinkommt ist Sache der Anwendung, der DB ist es herzlich egal.

Den Primärschlüssel sollte man übrigens nicht für irgendwelche anderen Sachen mißbrauchen, er hat eine spezielle Aufgabe, dabei sollte man es belassen.

[akretschmer]

warum ein VARCHAR für etwas, was eigentlich ein INT ist? Ich weiß, CPU-Zeit zum Vergleichen und Plattenplatz zum speichern ist relativ billig, sonst noch Gründe?

[marie123]

Guten Tag allerseits,

ich befasse mich schon eine Weile mit Datenbanken und habe auch schon häufiger Kundennummern eingebaut, indem ich einfach den Primärschlüssel einer geeigneten Tabelle verwendet habe.
Jetzt ist es aber so, dass die Kundennummern nicht mit 0001 beginnen sollen, sondern eher pseudo-zufällig wie 1425, 1426, 1427, ...
Weiterhin sollen die Kundennummern eine konstante Länge haben (die 4 Stellen sind nur ein Beispiel) und eventuell ein K wie Kundennummer als Präfix bekommen.
Hier frage ich mich, wie man das am sinnvollsten in einer Datenbank einbaut? Man könnte theoretisch alles in einer Spalte speichern ("K1425"), oder eine 1 Byte Extra-Spalte für den Buchstaben verwenden. Oder man speichert nur die Zahlen als Int und ergänzt den Rest in der Anwendung? Das Präfix war bei einem allgemeinen Suchfeld für effizientere Abfragen gedacht, damit bereits bei der Eingabe von K1... eben keine Telefonnummern, Namensfelder oder ähnliches durchsucht werden. Allerdings könnte man das auch in der Anwendung lösen, aber da fehlt mir die Erfahrung was sinnvoller ist.

Die verwendete Datenbank ist eine aktuelle MariaDB.

Ich danke allen fürs Lesen wünsche noch einen schönen Tag.
StorageWars

Daß die Kundennummer was anderes ist, als der Primärschlüssel, wurde ja nicht nur in den Antworten gesagt, sondern war dir ja von Anfang an klar. Die Sache mit der Extra-Spalte solltest du vergessen, du willst den Buchstaben ja nur, um die Kundennummer als Kundennummer zu identifizieren. Wenn er irgendeine Bedeutung haben würde (was nach deinen Worten dann nicht der Fall wäre), also z.B E für Einmalkunden, F für Firmenkunden usw., wäre es angebrachter, eine Tabelle "tbl_kundengruppe" zu haben und den Primärschlüssel dieser Tabelle in der Kundentabelle (?, vgl. unten) als Fremdschlüssel zu führen statt dieser Buchstabenspalte. Diesen Buchstaben könntest du als Präfix trotzdem führen, dann aber als Teil der Kundennummer und auf dem Wege, daß er automatisch aus der tbl_kundengruppe gezogen wird.

Am meisten Kopfschmerzen bereiten mit zwei andere Dinge:

1. Du sprichst von einem allmeinen Suchfeld und offenbar kann man dort auf Felder wie "Telefonnummern, Namensfelder oder ähnliches" suchen. Das würde bedeuten, daß man bei dir über Umwege an Kundendaten kommt. Das wäre ganz schlecht.
2. Du schreibst "Primärschlüssel einer geeigneten Tabelle", was auf ein zumindest fragwürdiges Datenmodell hindeutet. Kunden gehören in eine Tabelle "tbl_kunde" mit nichts anderem als Attributen von "Kunde" (darunter Fremdschlüssel).

Poste bitte mal eine db-Dump mit anonymisierten, aussagekräftigen Testdaten!

[protestix]

Sehr lesenswert finde ich diesen Beitrag
https://www.periscopedata.com/blog/better-sql-schema

In Abschnitt 4 geht es um PK und dort wird empfohlen immer ein PK als integer aufsteigend zu haben, unabhängig von anderen Nummern, da es das Leben als Entwickler zukünftig erleichtert.
Befolgt man diesen Rat, ist es egal ob die Kundenummer ein Präfix vorangestellt bekommen hat oder nicht. Wenn die Kundennummern aber aus anderen Gründen ein Zeichen vorangestellt bekommen soll, den sie sonst nicht hätte, dann weglassen, da es nicht Bestandteil ist und es nur Probleme bereiten kann.

Für den im Ausgangsbeitrag betrachteten Fall demnach eine Spalte als id als Primary Key und eine Spalte Kundennummer als Integer ohne vorangestellten Buchstaben.

Präfixe wie "tbl_" kommen vor allem in Access und VBA vor und sind in anderen Sprachen nicht sehr verbreitet, daher bitte vermeiden. Gründe dazu findet man zuhauf wenn man danach sucht.

[akretschmer]

Meep. INT hat einen begrenzten Zahlenraum. Wir haben typischerweise mehr als ein Ticket po Monat, wo man das dann spürt ...

[protestix]

Meep. INT hat einen begrenzten Zahlenraum.

nimmst dann halt bigint

[tomBuilder]

super offtopic :

Bei 4-5 stellen ist möglicherweise INT als Format gerade noch vertretbar
Sowie einem Kompletten refactoring (nicht nur der db ), sollte es mal über 7 stellen kommen, was ja immer noch gut in int passt.


Aufsteigende Kundennummern, am besten noch durch anzahl der stellen hierachisiert hat so was elitäres,

und einen wohl bekannten negativen beigeschmack. aber wers mag.

persöhnlich als kunde sagen mir alphanum als kndr zu.

[chorn]

Also wenn du dich für ein Präfix entscheidest, solltest du das mMn mit in der Datenbank im Primary Key speichern, andernfalls musst du das in deiner Applikation überall berücksichtigen, das heisst nicht nur beim Insert, sondern auch bei jeder Ausgabe, wenn du sowas wie Suche nach Kundennummer implementierst etc. - am Ende hast du sonst zwei Systeme, Applikation und Datenbank, die unterschiedliche funktionieren (Joins z.B.).

[erc]

warum ein VARCHAR für etwas, was eigentlich ein INT ist? Ich weiß, CPU-Zeit zum Vergleichen und Plattenplatz zum speichern ist relativ billig, sonst noch Gründe?

Kommt doch immer drauf an. Ist es wirklich eine Zahl oder nicht? Wenn ich die bei jeder Eingabe/Ausgabe formatieren muss, dann ist das für mich keine Zahl. Der Aufwand und möglichen Probleme stehen in keinen Verhältnis zu den paar Bytes. (+die zusätzliche Flexiblität)

Für mich steht hier nur die Frage im Raum, Kundennummer als PK, oder zusätzlich ein surrogate Key. Da würde ich sagen depends...

Sehr lesenswert finde ich diesen Beitrag
https://www.periscopedata.com/blog/better-sql-schema

In Abschnitt 4 geht es um PK und dort wird empfohlen immer ein PK als integer aufsteigend zu haben, unabhängig von anderen Nummern, da es das Leben als Entwickler zukünftig erleichtert.

Die Begründung muss man differenziert sehen. In dem Kontext ist das unsinn. "Nehm eine numerische ID, dann kannst du doppelte Datensätze löschen." Hätte ich gleich den natürlichen Schlüssel als PK genommen (Kundennummer), wären doppelte Einträge per Definition nicht möglich. (und selbst wenn, die Tabelle hat trotzdem ein PK)
In anderen Kontexten wie z.B. Logs/Protokollen stimm ich dem aber zu.

[Dormilich]

Ich werf mal noch UUIDs in den Raum. Damit hast du ausreichend Zahlenraum, zufällige Zeichenfolgen und man kann es als BINARY(16) speichern.

[hellbringer]

Für mich steht hier nur die Frage im Raum, Kundennummer als PK, oder zusätzlich ein surrogate Key. Da würde ich sagen depends...

Ich würde alle Werte, die für den Enduser im Frontend sichtbar sind, niemals als PK ausführen. Ich hatte schon so viele Fälle, wo dann plötzlich irgendwelche "IDs", Kundennummern, etc. geändert werden mussten, weil sich ein Kunde das so eingebildet hat bzw. die Daten mit einem Fremdsystem synchronisiert wurden, wo halt auf sowas geschi**en wurde.

[erc]

Ich würde alle Werte, die für den Enduser im Frontend sichtbar sind, niemals als PK ausführen. Ich hatte schon so viele Fälle, wo dann plötzlich irgendwelche "IDs", Kundennummern, etc. geändert werden mussten, weil sich ein Kunde das so eingebildet hat bzw. die Daten mit einem Fremdsystem synchronisiert wurden, wo halt auf sowas geschi**en wurde.

Wechselnde Ids oder wechselnde Identitäten sind ein ganz schwieriges Thema. Du sprichsts es ja schon an, Fremdsysteme. Die wenigsten Systeme sind abgeschottet, sondern kommunizieren mit anderen Systemen. An der Stelle hast du das Problem wieder. Nutzt du die ID mit der "kein" Mensch etwas Anfangen kann, oder die Nummer die sich ändern kann? Ganz fies... "geht nicht" kann hier eine Menge Ärger ersparen.