it-swarm.com.de

Verwenden Sie die UUID über der ID für das automatische Inkrementieren

Ich versuche, das DB-Schema meines neuen Projekts zu entwerfen, und benötige einige Vorschläge. Ich denke, für einige Tabellen eine zusätzliche Spalte zu haben, die eine UUID ist. Ich wollte hauptsächlich für Tabellen, die Daten enthalten, auf die über REST zugegriffen werden kann, daher möchte ich den Primärschlüssel nicht verfügbar machen. Ich mache mir Sorgen, dass ich beim Aktualisieren einer Tabelle eine weitere Abfrage ausführen muss, um den ursprünglichen Primärschlüssel zu verwenden.

Was denken Sie?

7
pik4

Der größte Mythos beim Entwerfen von Anwendungen ist, dass Sie nur einen Schlüssel haben dürfen.

Haben Sie mehrere Schlüssel, machen Sie es. Ihre Anwendung darf einen anderen Primärschlüssel als Ihre Datenbank haben. Ich weiß, dass dies zunächst seltsam klingen mag, aber Sie bekommen das Beste aus beiden Welten auf diesem Weg.

UUIDs haben viele Vorteile, machen aber im Allgemeinen schreckliche Clustered-Indizes. Sie können also einfach ein int als PK/Clustered-Index in Ihrer Datenbank verwenden, aber auch einen anderen eindeutigen Index für Ihre externe ID-Spalte haben. Dies erfordert möglicherweise einen zusätzlichen Join für viele Abfragen, aber das ist in Ordnung, da in relationalen DBs innere Joins in automatisch inkrementierten int-Spalten blitzschnell sind.

Ein weiterer Vorteil dieses Dual-Key-Ansatzes ist die einfache geografische Verteilung Ihrer Datenbank. Da UUIDs global eindeutig sind, müssen zwei geografisch getrennte DBs die Koordination ihrer Schlüssel nicht verlangsamen, solange Sie sicherstellen, dass die DB int PK die DB niemals verlässt und nicht vom Restdienst verwendet wird.

Hier ist ein weiterer Punkt: Ihre externe ID muss nicht einmal eine UUID sein. Es kann auch andere Optionen geben.

Das Externe kann auch ein Int oder eine Zeichenfolge oder der natürliche Schlüssel der Entität sein. etwas. Dies würde Ihre URLs weniger hässlich machen als eine UUID

Haben Sie keine Angst, mehrere Schlüssel zu haben. Es ist eine gute Sache, Ihren DB-Schlüssel vor den anderen API-Verbrauchern zu verstecken.


Die meisten Schlüssel, die ich jemals verwendet habe, waren zwei, aber in der richtigen Situation kann ich mir vorstellen, dass bis zu vier gerechtfertigt sind (DB-Schlüssel, Anwendungsschlüssel, Geschäftsschlüssel, Kundenschlüssel).

8
TheCatWhisperer

Es macht keinen Sinn, zwei Primärschlüssel zu haben.

  1. UUIDs lassen sich nur langsam indizieren.

Nein sind sie nicht. Machen Sie sich keine Gedanken mehr über arkane Zahlen wie Seiten und Fragmentierung und führen Sie einige Tests durch.

https://www.mssqltips.com/sqlservertip/5105/sql-server-performance-comparison-int-versus-guid/

http://byterot.blogspot.com/2013/02/performance-series-guids-vs-identity-rdbms-sql.html

https://www.cybertec-postgresql.com/de/int4-vs-int8-vs-uuid-vs-numeric-performance-on-bigger-joins/

In jedem Fall haben Sie das gleiche Problem, wenn Sie sowohl als auch die UUID indizieren

  1. UUIDs nehmen mehr Platz ein. Nun ja, solange Sie mit diesen niedrigen Höchstzahlen davonkommen können.

In jedem Fall, wenn Sie beide haben, ist es definitiv größer

  1. UUIDs sind hässlich. Nun, Sie möchten nicht eins eingeben, aber möchten Sie 13243444444431 oder Gdih £ $% d1 eingeben? Wenn Sie eine hübsche URL für SEO oder einen anderen Grund benötigen, gibt es bessere Lösungen als das Hinzufügen weiterer ID-Spalten zu Ihrer Tabelle.

Sequentielle Ints haben einige Hauptprobleme, die mit UUIDs gelöst werden. Eines davon ist das Erraten der nächsten ID oder der Anzahl der Bestellungen, die Sie angenommen haben.

Dies sind echte Sicherheits- und kommerzielle Bedenken und sollten allein ausreichen, um zu rechtfertigen, dass auto_inc ints überhaupt nicht verwendet werden.

Versuchen Sie nicht, die Probleme mit hackigen Lösungen zu beheben, sondern ersetzen Sie sie durch den Industriestandard.

5
Ewan

Wenn Ihr einziges Ziel darin besteht, den Primärschlüssel vor Ihrer REST - Schnittstelle) zu verbergen, würde ich davon abraten. Stattdessen wäre die Verschlüsselung Ihrer Schlüssel eine gute Lösung dafür.

Dies ist ein häufiges Problem, auf das ich schon oft gestoßen bin. Am Ende ging ich den Weg "benutze nur eine Nummer für die ID", was bedeutet, dass es für die Clients nicht ganz so hässlich ist, diese UUIDs zu sehen.

Die einzige andere Möglichkeit, wie Sie sich bereits entzogen haben, besteht darin, diese ID hinter einer Art Abfrage zu verbergen, der Sie Parameter zuführen müssen, um die richtige UUID abzurufen. Dies bedeutet jedoch, dass Sie diese möglicherweise auch verwenden Parameter als Primärschlüssel für Tabelle!

Ich würde sagen, es gibt keine Möglichkeit, REST (dh Statusübertragung eines Modells) zu tun, ohne die Instanz identifizieren zu können, die Sie RESTEN. Sie benötigen also einen Schlüssel, was auch immer Form, die der Schlüssel annimmt.

Wenn Ihr Anliegen aus Sicherheitsgründen besteht, sehe ich das Problem wie in Ihrem Validierungscode für Servernachrichten, nicht dass der Client IDs sieht. Wenn ein Hacker einige Daten aus Ihrer Tabelle laden möchte, muss er dazu keine IDs benötigen. Und Sie sollten auch die Anforderungen validieren, damit ohnehin keine zweifelhaften Dinge in Ihre Geschäftsschichten gelangen, d. H. Authentifizierung und Autorisierung von Nachrichten.

Um auf Ihre Frage zurückzukommen:

"Zugriff über REST, daher möchte ich den Primärschlüssel nicht verfügbar machen"

Ich denke, dass es das Gegenteil ist, Sie MÜSSEN den Primärschlüssel verfügbar machen, um REST auszuführen.

EDIT: Wie @Murph betonte, gibt es Angreifern tatsächlich eine bessere Chance, wenn Sie dem Client IDs geben - das wusste ich nicht. Es kann sein, dass andere Antworten hier (ich schaue auf die kürzeste, die sagt, dass der Schlüssel verschlüsselt werden soll) für Ihre Situation zutreffender sind. Edit 2: Scheint, UUIDs sind nicht sicherer als Ints ...

1
Dan Rayson

Das Problem bei der Verwendung von Primärschlüsseln als öffentliche Kennung für Ihre Entität besteht darin, dass Sie Details Ihrer Datenspeicherlösung an Ihre Kunden (und folglich während Ihrer gesamten Anwendung) weitergeben. Dies kann Auswirkungen auf die Sicherheit haben und dazu führen, dass Änderungen am Backend Ihrer Anwendungen komplizierter sein können. UUIDs können dieses Problem in gewisser Weise lösen, indem sie eine alternative Kennung bereitstellen, die völlig unabhängig von Ihrer Datenbanktechnologie ist.

UUIDs sind nur eine Lösung für dieses Problem, mit dem inhärenten Vorteil, dass sie für alle praktischen Zwecke garantiert einzigartig sind. Wenn Sie sich jedoch die Mühe gemacht haben, etwas anderes als den Primärschlüssel als Bezeichner zu verwenden, stellen Sie möglicherweise fest, dass die Verwendung einer beliebigen Zeichenfolge oder eines anderen numerischen Bezeichners bessere URLs liefert.

Eine weitere Überlegung ist, dass Sie wahrscheinlich einen Index für diese Entität benötigen, wenn Sie GUIDs/UUIDs als öffentliche Kennung für Ihre Entität verwenden. Da sie wesentlich mehr Speicherplatz als Ganzzahlen beanspruchen, ist Ihr Index viel größer.

1
richzilla