Was ist Ihre Meinung über die Verwendung von UUIDs als Datenbank-Datensatz-IDS, besonders in web-apps?
https://stackoverflow.com/questions/5949
-
08-06-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Ich habe es immer vorgezogen, um lange ganze zahlen als Primärschlüssel in Datenbanken, für die die Einfachheit und die (angenommene) Geschwindigkeit.Aber bei der Verwendung eines REST oder Schienen-wie-URL-Schema für die Objekt-Instanzen, würde ich dann am Ende mit URLs wie diese:
http://example.com/user/783
Und dann ist die Annahme, dass es auch Nutzer mit IDs 782, 781, ..., 2, und 1.Unter der Annahme, dass die web-app in Frage, die ist sicher genug ist, um zu verhindern, dass Menschen, die in anderen Nummern für die anderen Benutzer ohne Berechtigung, wird eine einfache, sequentiell zugewiesen Ersatzschlüssel", auch "leaks" die Gesamtzahl der Instanzen (älter als dieser), in diesem Fall Benutzer, die möglicherweise vertraulicher Informationen.(Für Beispiel, ich bin Benutzer #726 in stackoverflow.)
Würde ein UUID/GUID eine bessere Lösung?Dann könnte ich eine URL wie diese:
http://example.com/user/035a46e0-6550-11dd-ad8b-0800200c9a66
Nicht gerade kurz, aber es gibt weniger implizite Informationen über die Nutzer auf dem display.Sicher, es riecht nach "security through obscurity" ist kein Ersatz für eine ordnungsgemäße Sicherheit, aber es scheint zumindest ein wenig sicherer.
Ist das nutzen-Wert, die Kosten und Komplexität der Implementierung von UUIDs für web-adressierbares Objekt-Instanzen?Ich glaube, ich würde immer noch wollen, verwenden Sie integer-Spalten als Datenbank PKs nur um die Geschwindigkeit verbindet.
Es gibt auch die Frage von in-Datenbank Darstellung von UUIDs.Ich weiß, MySQL speichert Sie als 36-Zeichenfolgen.Postgres scheint zu haben eine mehr effiziente interne Darstellung (128-bit -?) aber ich habe es nicht versucht, mich.Jemand, der keine Erfahrung mit dieser?
Update:für diejenigen, die gefragt, die nur mit dem Benutzernamen in der URL (z.B., http://example.com/user/yukondude), das funktioniert auch für Objekt-Instanzen mit Namen, die eindeutig sind, aber was ist mit den Abermillionen von web-app Objekte, die kann wirklich nur identifiziert werden, durch die Zahl?Bestellungen, Transaktionen, Rechnungen, doppelte Bild, Namen, stackoverflow-Fragen, ...
Lösung
Ich kann nicht sagen, dass über die web-Seite zu Ihrer Frage.Aber uuids sind ideal für die n-tier-Anwendungen.PK generation dezentralisiert werden kann:jeder client erzeugt seine eigene pk ohne Gefahr von Kollision.Und der Geschwindigkeitsunterschied ist in der Regel gering.
Stellen Sie sicher, dass Ihre Datenbank unterstützt die effiziente Speicherung Datentyp (16 bytes, 128 bit).Zumindest Kodieren Sie die uuid-Zeichenfolge in base64 und verwenden Sie char(22).
Ich habe Sie ausgiebig mit Firebird und empfehlen.
Andere Tipps
Für was es Wert ist, gesehen hab ich lange ausführen gespeicherte Prozedur (9+ Sekunden) fallen nur ein paar hundert Millisekunden Laufzeit einfach durch Umschalten von GUID-Primärschlüssel zu zahlen.Das ist nicht zu sagen Anzeige eine GUID ist eine schlechte Idee, aber wie andere haben darauf hingewiesen, Beitritt auf Sie, und indizieren Sie, per definition, ist nicht annähernd so schnell, wie mit ganzen zahlen.
Ich kann dir Antworten, dass in SQL server, wenn Sie verwenden ein uniqueidentifier (GUID), datatype und verwenden Sie die NEWID () - Funktion zu erstellen, die Werte, die Sie bekommen schreckliche Zersplitterung, weil von Seite teilt.Der Grund dafür ist, dass bei der Verwendung von NEWID() der Wert generiert wird, nicht sequentiell.SQL 2005 fügte der NEWSEQUANTIAL () - Funktion Abhilfe schaffen
Eine Möglichkeit, weiterhin mit dem GUID und int ist ein guid und einen int in eine Tabelle, so dass die guid-maps zu den int.die guid wird verwendet, extern aber die int intern in der DB
zum Beispiel
457180FB-C2EA-48DF-8BEF-458573DA1C10 1
9A70FF3C-B7DA-4593-93AE-4A8945943C8A 2
1 und 2 werden verwendet, Verknüpfungen und die guids, die in der web-app.Diese Tabelle wird ziemlich eng und sollte Recht schnell Abfragen
Warum paar Primärschlüssel mit Ihr URI?
Warum nicht Ihr URI-Schlüssel lesbarer (oder unguessable, je nach Bedarf) und Ihre primären index integer-basiert, so dass Sie bekommen das beste aus beiden Welten.Viele blog-software bedeutet, dass, wo die ausgesetzt id der Eintrag ist gekennzeichnet durch ein 'slug' und die numerische id ist verborgen im inneren des Systems.
Der Vorteil hier ist, dass man nun ein wirklich schönes URL-Struktur, die ist gut für SEO.Offensichtlich für eine Transaktion dieser ist nicht eine gute Sache, aber für so etwas wie stackoverflow, es ist wichtig (siehe URL oben...).Erste Einzigartigkeit ist gar nicht so schwer.Wenn Sie wirklich besorgt, speichern einen hash von der slug in einer Tabelle irgendwo, und tun eine Suche vor dem einsetzen.
edit: Stackoverflow nicht ganz das system nutzen beschreibe ich, sehen Kerl in den Kommentar unten.
Anstatt URLs wie diese:
http://example.com/user/783
Warum nicht haben:
http://example.com/user/yukondude
Was ist freundlicher zu den Menschen und nicht Leck, kleines bisschen von Informationen?
Man könnte eine ganze Zahl, das ist die Nummer der Zeile, aber nicht durchgängig.Für Beispiel, Sie könnte nehmen Sie die 32-bit-der sequenzielle ID und ordnen Sie Sie mit einem festen Schema (für Beispiel, bit 1, wird bit 6, bit 2 wird bit 15, etc..).
Dies wird eine bidirektionale Verschlüsselung, und Sie können sich sicher sein, dass zwei verschiedene IDs haben immer verschiedene Verschlüsselungen.
Es wäre natürlich einfach zu entschlüsseln, wenn man sich die Zeit nimmt zu erzeugen, genug, IDs und bekommen das schema, aber, wenn ich das richtig verstehe Ihr problem, Sie wollen einfach nur, um nicht zu verschenken Informationen zu einfach.
Wir verwenden GUIDs als Primärschlüssel für alle unsere Tische als verdoppelt, wie die RowGUID-für MS-SQL-Server-Replikation.Macht es sehr leicht, wenn der Kunde plötzlich eröffnet ein Büro in einem anderen Teil der Welt...
Ich glaube nicht, dass eine GUID gibt Ihnen viele Vorteile.Benutzer hassen lange, unverständliche URLs.
Erstellen Sie eine kürzere ID, Sie können die Karte auf die URL, oder durchzusetzen, die eine eindeutige Benutzer-name-Konvention (http://example.com/user/brianly).Die Jungs von 37Signals wahrscheinlich würde Sie verspotten, sich Gedanken über so etwas, wenn es um eine web-app.
Übrigens können Sie nicht zwingen, Ihre Datenbank zu beginnen, erstellen von integer-IDs aus einem Basis-Wert.
Es hängt auch davon ab, was Sie über Pflege für Ihre Anwendung.Für die n-tier apps GUIDs/UUIDs sind einfacher zu implementieren und sind leichter zu portieren zwischen verschiedenen Datenbanken.Zu produzieren Integer-Schlüssel einige Datenbank-Unterstützung ein sequence-Objekt nativ und einige erfordern kundenspezifische Konstruktion einer Sequenz-Tabelle.
Integer-Schlüssel wahrscheinlich (ich habe keine zahlen) bieten einen Vorteil für Abfrage-und indizierungsleistung sowie Speicherplatz-Nutzung.Direkte DB-Abfragen ist auch viel leichter, verwenden Sie die Zifferntasten, weniger kopieren/einfügen, da Sie leichter zu erinnern.
Ich arbeite mit einem Studenten-management-system-UUID ' s in der form einer Ganzzahl.Sie haben eine Tabelle, die die nächsten eindeutige ID.
Obwohl dies wahrscheinlich eine gute Idee für ein architektonischer Sicht, es macht die Arbeit auf einer täglichen basis schwer.Manchmal gibt es eine Notwendigkeit, das zu tun bulk inserts und eine UUID macht dies sehr schwierig, in der Regel erfordern das schreiben einer cursor anstelle einer einfachen SELECT INTO-Anweisung.
Ich habe versucht, sowohl in den echten web-apps.
Meine Meinung ist, dass es ist vorzuziehen, Ganzzahlen und haben kurze, verständliche urls.
Als Entwickler, es fühlt sich ein bisschen schrecklich zu sehen, sequentielle Ganzzahlen und zu wissen, dass einige Informationen über total record count undicht ist, aber ehrlich - die meisten Leute wahrscheinlich nicht kümmern, und dass Informationen hat nie wirklich kritisch für mein Unternehmen.
Nachdem lange Zeit hässlich UUID urls scheint mir, wie viel mehr ein schalten Sie auf normale Benutzer.
Ich denke, dies ist eines dieser Probleme, die quasi-religiöse Debatten, und seine fast aussichtslos, zu sprechen.Ich würde einfach sagen, was Sie bevorzugen.In 99% der Systeme wird es egal, welche Art von Schlüssel Sie verwenden, damit der nutzen (angegeben in den anderen posts), die eine Art über die andere wird nie ein Problem sein.
Ich denke, mit ein GUID wäre die bessere Wahl in deiner situation.Es nimmt mehr Platz ein, aber es ist sicherer.
Youtube verwendet 11 Zeichen, die mit base64-Codierung bietet 11^64 Möglichkeiten, und Sie sind in der Regel ziemlich überschaubar zu schreiben.Ich Frage mich, ob die würde bieten eine bessere Leistung als ein full-on-UUID.UUID konvertiert base-64 wäre doppelt so groß, glaube ich.
Mehr Informationen können hier gefunden werden: https://www.youtube.com/watch?v=gocwRvLhDf8
Solange Sie ein DB-system mit effizienten Speicher, Festplatte ist Billig in diesen Tagen sowieso...
Ich weiß, GUID ' s a b*tch arbeiten mit einige Male und kommen mit einigen Abfrage-overhead, aber aus einer Sicherheits-Perspektive sind Sie ein Retter.
Denken Sicherheit durch Verschleierung " Sie passen gut, wenn die obskuren URI und Gebäude normalisiert DB mit Tabelle, Datensatz und die Spalte definiert die Sicherheit, die Sie kann nicht schief gehen mit der GUID ist, versuchen Sie es tut das mit integer-basierte IDS.
