Eindeutige Auftragsnummer generieren

Hallo,

ich programmiere gerade ein Warenwirtschaftssystem indem auch Aufträge erfasst werden. Nun möchte ich eine eindeutige Auftragsnummer generieren, die jeweils nur einmal vorkommt.

Mein Ansatz war dies über das Datum zu lösen z.B. so:

PHP-Code:

echo floor(date("dmYhis") / 4000000000); 


dies ist allerdings nicht gerade eine elegante Lösung. Das Ergebnis wäre hier eine 4 Stellige Zahl (was auch so gewünscht ist) allerdings ändern sich bei der Division ja meist nicht die ersten 4 Zahlen.

Ich dachte mir schon eine random Zahl generieren zu lassen und zu prüfen ob diese schon in der db vorhanden ist.. aber das ist meiner meinung nach etwas zu umständlich. Weiß jmd. wie ich sowas ganz enfach lösen kann?

Wie willst du eine eindeutige Nummer generieren ohne diese mit vorhandenen abzugleichen ?

Davon abgesehen halte ich es bei einem WaWi System für wesentlich sinnvoller aufsteigende Auftragsnummern zu haben wo der Nutzer am besten den Startwert einstellen kann. So zufällig generierte Nummern sind doch total verwirrend und ohne weitere Daten nicht zuzuordnen

Allenfalls: Auftragsnummer === MySql Id (jene ID, die der Auftrag in deiner DB erhält).
Wenn das ID Feld in der DB als Primary Key und autoincrement definiert ist, solltest du sicher sein können, dass eine Nummer immer eindeutig ist.

Gruss

tobi

stimmt eigentlich aufsteigende nummern macht mehr sinn

Danke

Für kosmetische Zwecke kannst du die DB ja einstellen, dass je Kundennummer hochgezählt wird.

Für die Kommunikation mit dem Kunden nimmst du dann Kundennummer, Auftragsnummer, Jahr; alles schön "gepaddet" und die Sonne scheint wieder

Ansonsten macht man für eine einzigartige ID einfach sowas:

PHP-Code:


$id=md5(time().rand(1, 999)); 


Spliffster, du hast vergessen, die zahl mit einer jeden dritten nachkommastelle von pi zwischen dem 2419. und dem 2711. zeichen zu multiplizieren.

meinst du, diese verrenkungen haben sinn? außerdem lässt sich deine id rekonstruieren/voraussagen.

Original geschrieben von penizillin
außerdem lässt sich deine id rekonstruieren/voraussagen.

Nur weil MD5 mittlerweile als "broken" gilt, glaubst du seine zeit- und zufallsabhängigen IDs "voraussagen" zu können? *sehenWill*


btw: uniqid() gibt's übrigens auch noch ...

nein, natürlich nicht.

ich sehe aber, dass er einen string hasht, der aus einem timestamp und einer zahl zwischen 1 und 999 besteht.

d.h. wenn ich die zeit des erstellens ungefähr weiß, kann ich durch banales bruteforce-n (das durch die integers ein kinderspiel von 3-4 zeilen ist) die id mit einer gewissen wahrscheinlichkeit voraussagen/rekonstruieren. (zwar keiner hohen für unsere makrowelt, aber immer noch einer viel höheren, als z.b. uniqid()).

Original geschrieben von penizillin
ich sehe aber, dass er einen string hasht, der aus einem timestamp und einer zahl zwischen 1 und 999 besteht.

Das siehst du jetzt, weil du den Code vorliegen hast.

Aber wenn du als Außenstehender nachher eine dieser IDs vor dir hast, dann sagst du doch bestimmt nicht mehr auf Anhieb, "ganz klar, das ist MD5 von Zeitstempel plus Zufallszahl zwischen 1 und 999!" ...

du hast natürlich recht, den code muss man dafür gesehen haben.

Verstehe das Problem nicht. Sobald das Schema bekannt ist, was bei Auftragsnummer ja der Fall ist, lässt sich so ziemlich jede Auftragsnummer rekonstruieren. Ansonsten müsste er ja jedesmal eine rein Zufällige ID vergeben, was ich für sein Vorhaben allerdings sehr uninteressant finde, denn meist sind die Auftragsnummer so gestalltet das gewisse Blöcke hinweise zur Art des Auftrages geben.

Nochmal kurz: Wo sind die Bedenken, wenn sich die Auftrags-/Vorgangsnummer rekonstruieren lässt?

in diesem zusammenhang - nirgendwo. jahlives hat bereits die richtige antwort gegeben. meine antwort auf Spliffsters beitrag hätte wohl in ot-tags gemusst.

Ah ok... ich würde auch jahlives vorschlag unterstützen, denn md5 klamotten machen es dem Kunden und Mitarbeitern am Telefon nicht gerade leicht: "Können Sie mir die Auftragsnummer nennen?", ab diesem Zeitpunkt hört man wohl ein tuten in der Leitung.

Ich will nur noch mal anmerken dass es mir dabei einzig um eine eindeutige/einzigartige ID ging. Bei der die Wahrscheinlichkeit, dass sie mehrfach erzeugt wird, auch unter ungünstigen Umständen relativ gering ist. Wobei uniqid() da sicher noch einiges vorteilhafter ist.

/Für einen externen Gebrauch ist diese natürlich nur bedingt nutzbar.