Die Verwendung von Tabellen, Spalten, Primärschlüsseln und Sekundärschlüsseln sind die Grundlagen für den Aufbau eines Datenbanksystems. Um die Datensätzen für Verarbeitung-, Zugriffs- und Speicherungszwecken nutzen zu können, werden in der Regel Tabellen mit einer ID als Primärschlüssel und Sekundärschlüssel angelegt. Als Datenformat verwendet man meistens ein 32-Bit-Integer und aktiviert das automatische Inkrementieren für die ID mit jeder neu angelegten Zeile. Die Verwendung eines 32-Bit-Integer kann aber in bestimmten Situationen zu Problemen führen, welche sich mit Hilfe von einer anderen universell eindeutigen Kennung (UUID) umgehen lässt.
Anhand dem folgenden Beispiel der Tabelle "Raumtechnik", vergibt die Datenbank immer automatisch eine freie ID.
CREATE TABLE Raumtechnik (Id INT NOT NULL AUTO_INCREMENT, Typ VARCHAR(255) NOT NULL, Beschreibung VARCHAR(255), PRIMARY KEY (Id));
Beispiel für ein logisches Datenbankkonzept.
Integer (UNSIGNED INT / BIGINT)
Eine Möglichkeit der Optimierung wäre hier einen vorzeichenlosen Integer (UNSIGNED INT) zu verwenden. Siehe auch "Im Dezember 2014 übertraf die Aufrufzahl von Psys Video „Gangnam Style“ auf YouTube das 32-Bit-Integer-Limit von 2 147 483 647."
Id UNSIGNED INT NOT NULL AUTO INCREMENT,
So lässt sich der Zahlenraum für IDs verdoppeln von 0 bis 4 294 967 295. Für sehr große Projekte sollte daher der 64-Bit-Integer UNSIGNED BIGINT verwendet werden. Aufpassen sollte man hier aber bei Web Applikationen (JSON Format), denn JavaScript-Engines der Browser haben hier irgendwann Probleme.
Probleme von Auto-Increments
Auto-Increments können bei der Verwendung von Datenbank Clustern ggf. ein Problem werden. Denn hier erhält jeder Node einen Schreibauftrag. Damit sie sich nicht bei jedem Insert auf die nächste ID einigen müssen erhöhen die Nodes die ID nicht um +1, es wird um die Anzahl der Nodes im Cluster erhöht.
Verwendet man in seiner Applikation Import- und Export-Funktionen, kann dies in einer relationalen Datenbank (über Schlüssel mit anderen Tabellen verknüpft) beim Importieren von Datensätze aus einer anderen Datenbank zu Problemen führen. So können Einträge bereits existieren und IDs sich doppeln, die Einträge müssten somit neue IDs bekommen und in allen anderen relevanten Tabellen müssen die Fremdschlüssel aktualisiert werden. Je nach dem wie groß der Import ist, kann es hier zu sehr großen verketteten Abhängigkeiten kommen.
Verwendet man IDs in seiner WebAPI (uni.org/klausurergebnis/123), kann dies schnell zum Sicherheitsproblem innerhalb der Anwendung führen. So lassen sich IDs sehr einfach erraten und ggf. fremde Ergebnisse abrufen.
UUIDs Universally Unique Identifier
UUIDs können in einer Datenbank als Alternative zum Integer verwendet werden und können die oben beschriebenen Probleme beim Importieren von Daten und Zusammenführen der Datensätze verhindern.
Die UUID (Request for Comments 4122) besteht aus einer 16-Byte-Zahl, ist hexadezimal notiert und in fünf Gruppen unterteilt:
550e8400-e29b-11d4-a716-446655440000
Microsoft nennt dieses Verfahren anders, nämlich GUID (Globally Unique Identifier).
Erzeugen lassen sich die UUIDs unter PostgreSQL mit Hilfe von gen_random_uuid () und bei Microsoft SQL Servern verwendet man beim Anlegen der Tabelle den UNIQUE IDENTIFIER.
CREATE TABLE Raumtechnik (unique_id UUID DEFAULT gen_random_uuid (), Typ VARCHAR(255) NOT NULL, Beschreibung VARCHAR(255), PRIMARY KEY (unique_id));
Zukünftige Konflikte sollten mit der Verwendung von UUIDs so gut wie ausgeschlossen sein, denn eine UUID ist einzigartig und kann nur einmal vergeben werden.
Keine Kommentare:
Kommentar veröffentlichen