Aufbau einer Buchungsnummer

[Tuupa]

Hallo,

stehe noch ganz am Anfang und versuche mich gerade an einer simplen Datenbank (MariaDB), für Kursbuchungen.
Mich beschäftigt auf der einen Seite diese Frage:
Wie, aus welchen Bestandteilen ist es sinnvoll eine Buchungs/Rechnungsnummer aufzubauen?
Welche Herangehensweisen, Konventionen gibt es im Alltag mit Datenbanken und Buchungen?

Die Buchungsnummern sollen Kursbuchungen abbilden, die meist von 2-3 Kursleitern gegeben werden. Was spricht z.B. dagegen, ein Erkennungsmerkmal der Kursleiter einzubauen, so dass man auf den ersten Blick an der Buchungsnummer sehen kann, von wem der Kurs gegeben wurde?
Wie würde man so ein Erkennungsmerkmal aufbauen, so dass es für den Umgang mit einer Datenbank/Buchungssystem passt und gleichzeitig für Menschen - ohne Verrenkung - lesbar ist?
Oder macht man so etwas überhaupt nicht und zieht immer die Kursbeschreibung heran, wenn man über eine Buchung mehr wissen will?

Die Überlegung war zu Anfang, die Initialen von z.B. zwei Kursleitern an den Anfang der Buchungsnummer zu stellen. Dann sind aber schon vier Zeichen vergeben, bei drei Kursleitern wären es sogar sechs. Wenn man nur die Anfangsbuchstaben z.B. (MM) nehmen würde, könnte es schnell zu durcheinander kommen, wenn Mark und Mara, und dann Martina und Michelle Kurse geben. Wenn Kursleiter wechseln oder es kommen neue dazu.

Was ich privat von Bestellungen kenne, sind hauptsächlich 6 bis 16 stellige Nummern. Selten ist auch mal etwas wie QMLK-GJUZ-FDSV dabei. Oder 1-2 Buchstaben + Nummer wie (JH-12345678).

Danke.

 

[akretschmer]

Wie würde man so ein Erkennungsmerkmal aufbauen, so dass es für den Umgang mit einer Datenbank/Buchungssystem passt und gleichzeitig für Menschen - ohne Verrenkung - lesbar ist?

Warum muß diese Buchungsnummer solche Details enthalten? Warum müssen alle Details an dieser Nummer schon direkt menschlich lesbar sein? Anfangsbuchstaben der Kursleiter:

• die Anzahl der Kursleiter ist sicherlich variabel
• gleiche Anfangsbuchstaben kommen vor
• Namen können sich später durch Hochzeit ändern

Relationale Datenbanken leben von Rlationen - daher der Name auch. Via Primary Keys und Fremdschlüsseln zwischen korrekt normalisierten Tabellen kannst Du zu einer Buchungsnummer wie '0815' alle Details ermitteln.

 

[Tuupa]

Danke.
In diesem Umfeld sind die Leute noch nicht so IT-affin, wie es heute durchaus üblich ist. Die Leute sind etwas älter und sind manuelle administrative Arbeit gewohnt usw.
Für die Kursleiter und die "ehrenamtliche" Organisation wäre es von Vorteil, ohne Datenbank schon allein an einer Buchungsnummer etwas ablesen zu können.
Aber ich verstehe, das man das eher nicht macht, wollte dazu aber eben gerne ein paar Ansichten aus einem Datenbankumfeld erfahren.

 

[akretschmer]

Für Anfänger würde ich übrigens eher von MySQL und Derivaten abraten. Und für Nicht-Mehr-Anfänger auch. Das hat einfach zu viele Fehler und zu wenige Features.

 

[Walter]

Für die Kursleiter und die "ehrenamtliche" Organisation wäre es von Vorteil, ohne Datenbank schon allein an einer Buchungsnummer etwas ablesen zu können.

Den Ausführungen von @akretschmer kann ich nur zustimmen.

Aber eine id bekommt im Normalfall kein Anwender zu sehen. Eine Tabelle ist üblicherweise so aufgebaut:

• id = von der Datenbank erzeugte Nummer die den Datensatz eindeutig identifiziert, bekommt der Anwender in der Regel nicht zu Gesicht
• Buchungsnummer oder Artikelnummer oder Kundennummer oder .... = mit der arbeitet der Anwender, wird auf allen Belegen aufgedruckt und kann sich notfalls auch ändern

 

[dabadepdu]

..Die Leute sind etwas älter und sind manuelle administrative Arbeit gewohnt usw.
Für die Kursleiter und die "ehrenamtliche" Organisation wäre es von Vorteil

Es kamen ja schon einige Einwände. Ich hatte selbst schon eine Antwort im Kopf und dabei an so fabelhafte Dinge wie die ISBN Nummern gedacht. Es gibt sicher dutzende negativ Beispiele, was aus solchen Ideen wird. Ich arbeite selbst viel und gern mit Datenbanken, aber ich bin sicher kein Numerologe. Naja, die Sache wird wohl abgehakt sein, aber ich bin dann zuletzt über dieses tolle Beispiel gestolpert:
Delphi-PRAXiS - Einzelnen Beitrag anzeigen - Delphi ISBN formatieren
(Code zur Formatierung einer ISBN-13)

Wer braucht sowas? Aus Programmierersicht oder aus Kundensicht? Meinetwegen weiß der kundige Buchhändler damit etwas anzufangen und kann anhand der Nummernbestandteile die Mondphasen bei Drucklegung hersagen oder mehr, aber wofür? Klar, das System ist in der Welt und man muss damit umgehen können, schlimm genug.

In dem Moment, wo man anfängt, Nummern so aufzubauen, beginnt die Uhr zu ticken, bis Dinge "geschehen", die nicht geplant waren.

Und noch mal aus technischer Perspektive:
Warum entstehen solche Nummern ursprünglich und "zwangsläufig" bzw. unvermeidbar? Das ist ziemlich simpel dann der Fall, wenn eindeutige Nummern aus unterschiedlichen Quellen kommen (müssen) und in einem gemeinsamen System funktionieren müssen. Die einzelne Nummernquelle bekommt in einem administrativen, einmaligen Akt von höherer Instanz selbst eine Identifikationsnummer, häufig auch alphanumerisch und das Recht, selbst, für sich, eindeutige Nummern zu erschaffen. Beides wir gepaart und fertig sind Nummern mit "Bedeutung". Gut, das war früher so, eine pragmatische Lösung für ein banales Problem. Und früher konnte man mit sowas "berühmt" werden. Der Erfinder des Barcodes, EAN, GTIN oder wie sie alle heißen. Toll! Also wirklich, das war mal ein Knaller.
Heute gibt es auch andere Möglichkeiten. Aber wenn man sich sowas mal klar macht, kann man vielleicht sachgerechter mit der Idee solcher Nummern umgehen.