ID Best Practices für Datenbanken
Ich Frage mich, was die best practices wurden für den Aufbau und die Speicherung von IDs. Vor ein paar Jahren, ein professor erzählte mir über die Gefahren eines schlecht konstruierten ID-system, mit dem Social-Security-Nummer als Beispiel. Insbesondere, weil Sozialversicherungsnummern haben keine Fehler-Erkennung... es ist unmöglich zu sagen, den Unterschied zwischen einem 9-stellige Zeichenfolge und eine gültige SSN. Und jetzt Behörden müssen Dinge wie Nachname + Sozialversicherungsnummer oder Geburtstag + SSN zu behalten Ihre Daten und sorgen für deren Verifikation. Plus, Ihre Sozialversicherungsnummer ist auch etwas vorhersehbar, je nachdem, wo Sie geboren wurden.
Moment Baue ich eine User-Datenbank... und basierend auf dieser Beratung "userid mediumint auto_increment" wäre inakzeptabel. Vor allem, wenn ich Plane, verwenden Sie diese ID, da die primäre Identifikation für den Benutzer. (wenn ich zum Beispiel erlauben Sie den Benutzern, ändern Sie Ihren Benutzernamen, dann wird der Benutzername wäre schwieriger zu verfolgen als die numerische userid... erfordern cascading foreign-keys und so weiter.) E-Mails ändern, Benutzernamen ändern, Passwörter ändern,... aber die BenutzerID sollte konstant bleiben, für immer.
Klar, auto_increment ist nur für surrogate_keys. Das heißt, Ihre sinnvolle Verknüpfung nur, wenn Sie bereits eine primäre Identifikation Mechanismus, aber es sollte nicht verwendet werden, als eine "angeborene " identifier" für die Daten. Erstellen einer zufälligen UUID sieht interessant aus, aber die Zufälligkeit macht mich aus.
Und so Frage ich: was ist die best practices für die Schaffung eines "primary key" Identifikationsnummer?
- Was ist mit Ihrem professor, der Ratschläge führte Sie zu dem Schluss, dass der auto-increment Integer geeignet waren als eindeutige Bezeichner für die Benutzer-Daten?
- Auto-increment Integer sind vorhersehbar und keine form von Fehler-Erkennung. Zumindest würde ich erwarten, dass eine "professionelle" ID Praxis zu sein, etwas unberechenbar und selbst-Identifikation. Zum Beispiel Kreditkarten-Nummern haben, einer Prüfziffer, was bedeutet, dass, wenn ein Mensch den Arten einer Kreditkarte falsch, es ist nur eine 1/10 chance, dass es angenommen werden würde. Sie sind auch Recht unberechenbar, so kann ein hacker nicht nur zufällige Kreditkarten-Nummern in Amazon und hoffe, dass er auch eine gültige Kreditkartennummer. Ebenso ein hacker sollte nicht sprengen Wörterbuch-Attacken zu vorhersagbaren UIDs.
- Ich verstehe nicht, den Vergleich auch hier. Ich wäre fassungslos, wenn Kreditkarten-Unternehmen verwendet Kreditkarte zahlen, wie die Datenbank-IDs, anstatt speichert Sie als einige stark gesicherte Attribut in einer Tabelle. Dein Kommentar impliziert, dass das wissen über eine ID wäre eine Art Hintertür in der Datenbank. Authentifizierung Art der Verteidigung gegen unbefugten Zugriff auf Daten, die nicht wissen von random-Datenbank Werte.
- Ich behaupte, dass in diesem Tag und Alter, dass die Prüfziffer auf eine CC ist nicht annähernd so nützlich, wie Sie eine Abfrage gegen die CC-Firma mit der Nummer, dem Namen und CCV-Wert zu überprüfen, zu seinem Besitzer. Der einzige Weg, um sicher wissen, wenn die CC gültig ist, ist eine Abfrage der maßgebliche Quelle.
- Ich will damit nicht sagen, dass die CC-Nummern sind validiert, indem Sie Ihre Prüfziffer allein. Allerdings scheint es von Vorteil sein, mit wenig Kosten. Die Prüfziffer kann leicht implementiert werden, in effiziente Javascript, und kann der Benutzer sofort weiß, dass er einen Fehler gemacht, während Sie Tippen. IE: Prüfziffern gibt es für die usability, und nicht für Sicherheit.
- Ich bin nicht einverstanden, dass es einige Kosten, die vor allem rund um ändern. Es ist Aufwand, der mit der Herleitung der Prüfziffer-Algorithmus und Pflege es in das Gesicht einer änderung der Kennung. Kreditkarten sind sehr verbreitet, dass viele Unternehmen erzeugen kann, die Werte (ähnlich wie die Reederei Beispiel gab ich in meinem post). Wenn das system gebaut wird immer die einzige maßgebliche Quelle, dann eine Prüfziffer enthält fast keinen Vorteil IMO.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Du verwechselst internen Datenbank-Funktionalität mit externen such-Kriterien.
Auto-Inkrement-Surrogat-Schlüssel sind nützlich für die interne Anwendung verwenden. Nie gehen diese an den Benutzer. Identifizierung von business-Objekten, egal ob es ein user oder eine Rechnung, fertig sind mit einzigartigen Informationen über das Objekt, wie Sozialversicherungsnummern, Kreditkartennummern oder Geburtsdatum. Verwenden Sie so viel info wie nötig, um die Identifizierung des Objekts.
Ich empfehle, dass, wenn Sie müssen liefern einige neu erfunden-ID-Wert für jeden Kunden, dass es NICHT das Feld, das Sie verknüpfen Sie alle Kunden-Daten-Tabellen auf.
Die beste Praxis ist die Verwendung von einer auto-increment-integer. Es gibt keinen wirklichen Grund, es sollte nicht verwendet werden, als eine "angeborene identifier". Es wird eine möglichst kompakte Nutzung im Fremdschlüssel und am schnellsten sucht. Fast alle anderen Werte ändern können und ist ungeeignet für die Verwendung als ein Schlüssel.
Vergleich Sozialversicherungsnummern, um auto-increment Integer ist äpfel und Orangen. Persönlich ich vermeiden, dass die GUIDs /UUIDs /UIDs, es sei denn, es werden so viele Datensätze in der Tabelle, dass es ineffizient oder unsinnig zu benutzen, eine ganze Zahl.
Es ist sehr selten, dass man eine wahre, Natürliche Schlüssel. Was scheint heute einzigartig kann sich morgen ändern, basierend auf business-Anforderungen /Gesetze.
Basierend auf unserem Gespräch oben in den Kommentaren, ich bin dieses posting als Antwort. Es scheint, als ob Sie glauben, dass mit einer zufälligen, eindeutigen ID zugewiesen, um Ihren Nutzern würde Sie mit genug Sicherheit, dass Sie könnte darauf verzichten, normal Methoden der Authentifizierung.
Jedenfalls, ich bin verwirrt durch Ihre Vergleiche zwischen den gesicherten Daten und auto-increment, integer-basierte ID-Spalten in der user-Tabellen. Diese beiden Arten von Daten sollten nie vermischt. Ihre Kreditkarten-Unternehmen sollte nicht mit einem CCN als Primärschlüssel in einer Datenbank-Tabelle, und die Regierung sollte nicht mit Ihrem Namen oder Sozialversicherungsnummer als Primärschlüssel in der Datenbank Tabellen.
Warum sollte Sie (oder jemand) authentifizieren von Benutzern mit nur wissen einige gesicherte Daten? Die Konzerne sind nicht mehr erlaubt zum authentifizieren von Benutzern basierend auf Ihrer Sozialversicherungsnummern, und ich weiß, dass meine Kreditkarten-Unternehmen nicht identifizieren mich und meine CCN (vor allem, da ich mehr als eine haben, und habe die Karte zahlen auf den Konten mehrfach geändert).
Selbst wenn Sie implementiert eine UUID und erzeugt einige beliebige Zufallszahl, es ist immer noch genau das: ein Anzahl. Die Active Directory-Authentifizierung verwendet GUIDs für Ihre IDs, sondern auch erfordert, dass Benutzer geben die Benutzernamen und Kennwörter. Die Verwendung einer größeren oder kleineren Datentyp als ID-Spalte heißt nicht, ich kann meine Hände waschen, einige andere Art von Authentifizierung oder Sicherheit.
Dies ist, was Sequenzen an, in denen entworfen, um zu lösen. Erstellen Sie ein Objekt, das atomar erhöht werden pro einfügen. In einigen DBs, der automatisch inkrementierten integer, und in anderen ist es ein Sequenz-Objekt, aber die Idee ist die gleiche, dh einen Schlüssel erstellen, können Sie nicht in Konflikt und ist einzigartig.
Auch UUIDs als ID ist in Ordnung und ich habe es verwendet, bevor Sie aus besonderen Gründen. Warum hat der Zufall "schalten Sie aus"? Es gibt praktisch keine chance, einen Konflikt.
Am Ende des Tages, die Möglichkeit zu überprüfen, ob eine bestimmte Benutzer-id gilt, ist das system selbst. I. e., Ihr system ist die maßgebliche Quelle für diese Kennungen. Ist 555-45-9999 eine gültige SSN? Der einzige Weg, um sicher wissen, ist, dass Sie Soziale Sicherheit suchen Sie es und passen Sie auf den Namen der person, die behauptet haben, dass Nummer. Sicher, wir können die SSN id-Schema um eine vorläufige Vermutung, ob es gültig ist. Jedoch, nur eine Suche in Ihrem system wird uns sagen, für Sie sicher. Die Notwendigkeit für Prüfziffern die entstehen würden, in stark verteilten Systemen, in denen, zum Beispiel, möchten Sie vielleicht, um andere Menschen zu generieren, die zahlen, geehrt durch Ihr system (z.B. Reedereien, mit denen Kunden erzeugen Ihre eigene tracking-Nummern). Da es Ihr system ist, gehen Sie zum generieren der Kennungen in einer automatisierten Art und Weise, die am besten eine Prüfziffer für Sie tut, ist zu helfen, in eine rudimentäre Mode, mit der Validierung der für die Dateneingabe oder-Suche.