Eindeutige (unique), möglichste einfache ID erstellen

Dieses Thema im Forum "Web-Programmierung" wurde erstellt von Jakob, 01.06.2005.

  1. Jakob

    Jakob Thread Starter MacUser Mitglied

    Beiträge:
    1.067
    Zustimmungen:
    21
    MacUser seit:
    05.01.2004
    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/
     
  2. cron

    cron Gast

    Die ID, die dort erstellt wird, besteht aus einem W, einem zufälligen Zeichen, der aktuellen Zeit und einem zufällig generierten Zahlencode. Ich denke, das dürfte reichen. :)
     
    Zuletzt von einem Moderator bearbeitet: 01.06.2005
  3. Jakob

    Jakob Thread Starter MacUser Mitglied

    Beiträge:
    1.067
    Zustimmungen:
    21
    MacUser seit:
    05.01.2004
    <schnipp>
     
    Zuletzt bearbeitet: 01.06.2005
  4. Jakob

    Jakob Thread Starter MacUser Mitglied

    Beiträge:
    1.067
    Zustimmungen:
    21
    MacUser seit:
    05.01.2004
    <schnapp>
     
    Zuletzt bearbeitet: 01.06.2005
  5. Jakob

    Jakob Thread Starter MacUser Mitglied

    Beiträge:
    1.067
    Zustimmungen:
    21
    MacUser seit:
    05.01.2004
    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: 01.06.2005
  6. wegus

    wegus MacUser Mitglied

    Beiträge:
    15.042
    Zustimmungen:
    1.317
    MacUser seit:
    13.09.2004
    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.
     
  7. Jakob

    Jakob Thread Starter MacUser Mitglied

    Beiträge:
    1.067
    Zustimmungen:
    21
    MacUser seit:
    05.01.2004
    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…
     
  8. wegus

    wegus MacUser Mitglied

    Beiträge:
    15.042
    Zustimmungen:
    1.317
    MacUser seit:
    13.09.2004
    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.
     
  9. master_p

    master_p MacUser Mitglied

    Beiträge:
    1.065
    Zustimmungen:
    23
    MacUser seit:
    31.01.2005
    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.
     
  10. wegus

    wegus MacUser Mitglied

    Beiträge:
    15.042
    Zustimmungen:
    1.317
    MacUser seit:
    13.09.2004
    Hash-Werte sind definitiv nicht unique! Unterschiedliche Eingaben haben durchaus identische Hashwerte!