Die 2 größten Fallen bei der Vergabe von IDs

IDs, oder Identifiers (Identifikatoren) sind überall. Im Systems Engineering arbeiten wir mit IDs, die Anforderungen eindeutig identifizieren. Im PLM haben wir Teilenummern. Aber auch außerhalb von unserem Fachgebiet haben wir es mit IDs zu tun: Webseiten haben URLs, bzw. inzwischen URIs (das I steht für „Identifier“). Bücher haben eine ISDN. Und Orte haben Adressen.

Identifikatoren sind überall und sie sind wichtig. Deswegen sollten wir uns ein paar Gedanken machen, bevor wir uns auf ein Schema für die Vergabe von IDs festlegen. Hier die 2 größten Fallen.

Bei der Vergabe von Identifikatoren ist vieles zu berücksichtigen. Jedoch gibt es zwei Aspekte, die besonders häufig zu Problemen führen: Der Scope für die Gültigkeit und die mögliche Bedeutung der ID.

Falle 1: Scope wurde nicht berücksichtigt

Der Scope beschreibt den Gültigkeitsbereich einer ID. Außerhalb des Scopes könnte die ID mehrdeutig sein.

Ein klassisches Beispiel aus dem täglichen Leben ist die ISBN-Nummer auf Büchern. Die Nummer identifiziert das Buch eindeutig. Doch am Ende handelt es sich einfach um eine 10-, bzw. 13-stellige Nummer. In einem anderen Kontext könnte die Nummer bedeutungslos sein, eine andere Bedeutung haben oder mehrdeutig sein.

Schlimmer noch: In dem Moment, wo wir mit Datenbanken arbeiten, müssen wir erst recht aufpassen. Datenbanken generieren IDs für ihre Einträge, egal um welche Art von Datenbank es sich handelt. Hier besteht die Versuchung, diese auch für die Identifizierung außerhalb der Datenbank zu nutzen. Das geht zwar in der Regel gut, hat dennoch Nachteile: Migrationen und automatisches Testen werden dadurch schwieriger. Möglicherweise legen wir uns damit auf eine bestimmte Datenbank fest, ohne es zu wissen. Und es kann die Migration von Daten erschweren.

Generiere die ID immer auf Anwendungsebene, benutze nicht Datenbank-generierte IDs

Three Issues With Using Database Generated IDs

Problematisch kann es auch dann werden, wenn dasselbe System (oder die dieselbe Datenbank) mehrfach eingesetzt und integriert werden soll. In dem Falle haben wir es dann mit nicht-eindeutigen Bezeichnern zu tun.

Lösung: Scope analysieren, IDs von der Anwendung generieren

Daher macht es Sinn, sich frühzeitig ein paar Gedanken über den Scope zu machen und darauf basierend passende IDs auf der Anwendungsebene zu generieren. Grundsätzlich ist es sinnvoll, dass wir uns über alle erforderlichen Eigenschaften der IDs Gedanken machen. Dazu gleich noch mehr.

Manchmal können wir den Scope nicht von Anfang an einschätzen. In dem Fall ist möglicherweise ein global eindeutiger Identifikator sinnvoll. Auch hier haben wir mehrere Optionen.

Global eindeutige IDs

Auch hier haben wir viele Möglichkeiten. Je nach Anwendungsfall sind die folgenden zwei die Wichtigsten:

Wir können Universell eindeutige IDs nutzen, sogenannte UUIDs. Diese gibt es garantiert weltweit kein zweites Mal. Beispiel:

550e8400-e29b-11d4-a716-446655440000

UUIDs haben auch Nachteile. Zum Beispiel enthalten sie keine Sequenzinformationen und sind auch nicht sonderlich gut für Menschen geeignet. Falls diese Eigentschaften wichtig sind, wir aber trotzdem den Scope nicht einschätzen können, sollten wir mit Namesräumen arbeiten. Der bekannteste Ansatz dazu ist die URI (Uniform Resource Identifier). Diese sehen wie eine Webadresse aus. Und in der Tat, viele Webadressen sind auch URIs.

Eine URI hat den Vorteil, dass sie gekürzt werden kann, falls der Scope bekannt ist. Hier ein Beispiel:

  foo://example.com:8042/over/there?name=ferret#nose
  \_/ \________________/\_________/ \_________/ \__/
   |          |             |            |        |
scheme    authority        path        query   fragment
   |   _____________________|__
  / \ /                        \
  urn:example:animal:ferret:nose

Wenn wir bspw. wissen, dass wir auf dem Server example.com:8042 sind, dann reicht alles ab dem Pfad (path) aus, um die Ressource eindeutig zu identifizieren.

An dieser Stelle fragen wir uns sicher: Haben die Teile des Identifikators eine bestimmte Bedeutung? Und damit sind wir bei Falle 2:

Falle 2: Die ID hat eine Semantik

Als Menschen freuen wir uns, wenn wir eine ID sehen und sofort wissen, worum es geht. Das klassische Beispiel hierfür ist das Fahrzeugkennzeichen. Der Buchstabe im blauen Feld identifiziert das Land, die ersten Buchstaben die Stadt.

Im Falle von Fahrzeugkennzeichen handelt es sich um einen standardisierten Identifizierter, dessen Bedeutung sich über die Jahre wenig ändern wird, dann kann dies in Ordnung sein. Doch gerade in einem sich schnell wandelnden Umfeld schaffen wir schnell mit semantischen IDs mehr Probleme als wir lösen, da wir uns stark einschränken. Noch schlimmer wird es, falls sich die Bedeutung des identifizierten Elements ändern kann, zum Beispiel durch Technologiewandel. Der folgende Artikel beschreibt dies im Detail anhand „sprechender Teilenummern“:

Wir müssen hier aufpassen, dass wir Struktur und Semantik nicht verwechseln: Zum Beispiel haben die oben gezeigten URIs eine klare Struktur. Jedes Strukturelement hat eine Rolle (scheme, authority, path). In der Praxis kommen wir selten umhin, gewisse Strukturen zu zeigen. Doch diese Strukturen sollten über die Struktur hinaus keine vorgegebene Bedeutung haben.

Fazit

Mit softwarelastigen und immer stärker vernetzten Systemen steigt die Bedeutung von Identifikatoren. IDs sind kein Hexenwerk und viele Frameworks helfen uns, einfach und sicher IDs zu erzeugen. Dennoch: Wir sollten uns unbedingt vor Umsetzung Gedanken über den Scope der IDs machen und Bedeutung aus der Struktur der Identifikatoren heraushalten. Damit können wir uns langfristig eine Menge Ärger ersparen.

Bildquelle: Pixabay