STP058: Identifier

Da die Zeiten von Karteikarten in Büros und auf Ämtern leider vorbei sind, braucht es nun andere Wege, um Personen zu identifizieren. Doch nicht nur störende Kundschaft will wiedererkannt werden...

Shownotes

Wir haben einiges an Feedback bekommen, siehe Ende der Shownotes. Zuerst zum eigentlichen Thema:

• Identifier (ID): eindeutiges Kennzeichen zur Unterscheidung gleichartiger Objekte oder Individuen

  • während des Softwaredesign (z.B. beim Entwurf des Datenbankschemas): Entscheidung darüber, welche Identifier für welche Kategorien von Objekten verwendet werden

• Identifier für Menschen: Falsehoods Programmers Believe About Names

  • bei deutschen Behörden üblich: das Tupel aus Name und Geburtsdatum und evtl. Geburtsort -> immer noch nicht ganz eindeutig
  • bei Benutzerkonten im wesentlichen drei Optionen:
    • fortlaufende Nummern (Vorteile: im Speicher kompakt darstellbar, robustes Pseudonym; Nachteile: leakt das Alter des Kontos, rare kurze Nummern vermitteln Status), siehe z.B. ICQ-Kontonummern (frühe 2000er)
    • frei wählbare Benutzernamen (Vorteile: eingängig, Pseudonymität möglich; Nachteile: belohnt frühe Registrierung, fördert Name-Squatting)
    • E-Mail-Adressen (Vorteile: enthält implizit eine Kontaktmöglichkeit, wird seltener vergessen als eine Nummer oder ein frei wählbarer Name; Nachteile: muss vertraulich behandelt werden, beim Wechsel der Mail-Adresse evtl. Neuanmeldung erforderlich)

• auch bei Objekten oder Datenstrukturen eine gute Option: fortlaufende Nummern

  • im deutschen Handelsrecht bei Rechnungen sogar in gewissem Rahmen rechtlich vorgeschrieben
  • Vorteil: Hochzählen ist trivial umzusetzen
  • Vorteil: kompakte Darstellung im Speicher (z.B. nur 4 Byte bei einer Gesamtzahl unter 4 Mrd. Objekte) -> insb. wichtig bei Kreuzreferenzen
  • Nachteil: ab und zu hat man doch mehr Objekte als erwartet und muss mühselig auf größere Zahlen umstellen (z.B. bei über 4 Mrd. Objekten von 32-Bit-Zahlen auf 64-Bit-Zahlen) -> Beispiel bei der Schachwebseite chess.com
  • Nachteil: in verteilten Systemen (siehe STP027) braucht man eine zentrale ID-Vergabestelle oder einen aufwändigen Konsensalgorithmus -> Geht das besser?

• Universally Unique Identifier (UUID) gemäß RFC 4122

  • Idee: mit dem Schritt von 64 Bit auf 128 Bit so viele mögliche Werte, dass man z.B. bei zufälliger Wahl eine absurd geringe Kollisionswahrscheinlichkeit hat
  • Darstellung in Text meistens als Hexadezimalzahl in Gruppen von 8, 4, 4, 4 und 12 Stellen; Beispiel: 8b4b72a2-55dd-4ab7-b239-bb9caad9107a
  • mehrere verschiedene Formate: heutzutage am häufigsten UUIDv4 (mit rein zufälligen Zahlen, außer dass die 13. Hexadezimalstelle die Formatzahl "4" enthält)
  • Vorteil: in verteilten Systemen keine Koordination bei der Vergabe erforderlich
  • Nachteil: etwas weniger kompakt, insb. wenn die UUID wie oft üblich als Text abgespeichert wird
  • Nachteil insb. bei UUIDv4: keine sinnvolle Sortierung -> Alternativvorschläge wie UUIDv7 oder ULID stellen eine sortierbar kodierte Form des Erstellung