Eindeutige (unique), möglichste einfache ID erstellen

Jakob

Aktives Mitglied
Thread Starter
Dabei seit
05.01.2004
Beiträge
1.070
Reaktionspunkte
21
Hallo,

habe hier ein Kontaktformular, was in die Datenbank schreibt und eMails von der Kontaktaufnahme verschickt. Unter anderem zum Absender, eine Art "Wir haben Ihre Anfrage angenommen und bearbeiten sie bestimmt."

In dieser Mail soll auch eine ID stehen, die eindeutig ist und mit in die Datenbank geschrieben wird. Damit man jede Mail mit dem jeweiligen Eintrag zuordnen kann.

Die ID der Datenbank will ich aus Sicherheitsgründen und weil's blöd aussieht nicht nehmen. (z.B. "Ihre ID ist die 18")

Wie kann ich denn so eine ID generieren? Am liebsten sowas wie im Apple-Shop "W1234567". Aber wie gehe ich sicher, dass die nach 50.000 Anfragen immer noch einzigartig ist?

Danke!

P.S.: Ich habe ein Seite dazu gefunden, aber überblicke nicht, ob das wirklich genug random ist: http://lab.artlung.com/php/make-unique-id/
 
<schnipp>
 
Zuletzt bearbeitet:
<schnapp>
 
Zuletzt bearbeitet:
So… ich sehe gerade das gibt ja viel mehr aus, als da angezeigt. Das ist mir zu viel.

Ich denke ich stutze das auf das Prefix + einem random character + dem Unix time stamp.

Aber das ist irgendwie nich sicher, da kann ja jeder mal in etwa schätzen und dann gibt er sich als jemand anderes aus. Gibt es keine Möglichkeit nen sicheren ca. 15-teiligen String zu haben?
 
Zuletzt bearbeitet:
Darüber debattieren Kryptologen doch schon recht lange! Je mehr Sicherheit Du willst, um so länger muß der Schlüssel sein. Und um so wirklich zufällig die Generierung der Zeichen. Wenn Du von 8-Bit Zeichensätzen ausgehst, hast Du doch bei 15-Zeichen maximal 15^256 mögliche Schlüssel. Egal wie Du sie generierst. Der timestamp ist dabei nat. sehr vorhersagbar. Wenn Du mehr Sicherheit brauchst, mußt Du die Schlüssellänge der ID erhöhen. Damit erhöhst Du den Raum der möglichen Belegungen und somit verringert sich die Chance einer Doppelbelegung.

So wie ich Dich verstehe geht es doch nur um die Einzigartigkeit um eine eideutige Zuordnung zu haben. Da bietet sich die DB förmlich an, weil sie Doppelbelegungen per Deklaration verhindern wird. Mein Tipp, nimm die ID und adier einfach nen Offset dazu. Sowas wie

AYYYYMM-KdNr-1000000

A steht für Anfrage
YYYY steht für das Jahr in dem die Anfrage kam
MM steht für den Monat
KdNr steht für die Kundennummer
alles nach 2ten dem Bindestrich ist die ID der Anfrage

somit müßtest Du nur die erste ID in der DB auf eine Million setzen ( bei Postgres geht das, bei mysql weiß ich es nicht!). Somit hättest Du ne zeitliche Zuordnung durch die Nummer, eine Zuordnung zum Kunden durch die ggf. vorhandene KdNr. und eine eineindeutige Nummer, da die DB keinen Primärindex doppelt vergeben wird.
 
Mein größtes Problem besteht darin:
Jemand ruft bei denen an, sagt er hat die Nummer in der Mail und möchte jetzt was haben.
Ich muss mal ne Nacht drüber schlafen, ob es ein Sicherheitsrisiko ist, wenn andere diese Nummer erraten können. Ein Login oder so gibt es ja nicht. Es ist nur, damit Kunde und Firma im Zweifel eine wirklich eindeutige Beziehung haben.

Dein Ansatz ist zwar gut, aber die ganzen Infos bis auf die zufällige ID hab ich ja schon in der Datenbank. Widerstrebt mir, die nochmal in die Bearbeitungsnummer reinzunehmen.

Wenn ich nen zufällig generierten String mit einem Buchstaben + 11 Ziffern habe, hab ich doch 26 * 11^10 Möglichkeiten, oder? Das wären dann 679 Milliarden Möglichkeiten, das sollte doch die nächsten 2-5 Jahre reichen bei ca. 500-1000 Kontaktaufnahmen pro Monat, also rund 50.000 Aufnahmen, oder?

Stimmt die Rechnung? Hät ich doch in Statistik besser aufgepasst…
 
Mein Einwand war die Syncronisierung und das macht am Besten die DB. Nat sind die anderen Angaben redundant. Laß sie weg...

damit hast Du sicher keine Doppelbelegungen. Als unsigned int kannst Du dann 4.2 Milliarden Anfragen handeln! Ist Dir das zuwenig, nimmst Du halt ne 2te Spalte dazu. 4.2 Millarden^2 dürfte doch reichen.
 
Wie sieht's denn aus, wenn man den aktuellen Timestamp mit MD5 "verschlüsseln" lässt. Damit hat man dann einen ziemlich guten und sicheren Code, der sicherlich auch recht selten zweimal vorkommt.
 
Hash-Werte sind definitiv nicht unique! Unterschiedliche Eingaben haben durchaus identische Hashwerte!
 
Ein Datum und Zeitstempel ist doch "relativ" sicher, anbetracht der Tatsache, daß er auch noch in der DB abgelegt sein muß, um "gültig" zu sein. Kombiniert mit Firmennamen und Namen der Person (wer stellt sich schon am Telefon nicht vor) dürfte das ganze ziemlich einzigartig sein.

Ich würde zwecks der Lesbarkeit allerdings die Kunden nicht mit 15-stelligen Zahlencodes nerven. Ggf. vielleicht in einfach zu lesender Form: 443 452 685 134 543.

No.
 
Zurück
Oben Unten