Sollte ein Ersatzschlüssel jemals einem Benutzer zugänglich gemacht werden?

14

In einer Tabelle, die keinen natürlichen Schlüssel enthält, ist es häufig weiterhin nützlich, dass Benutzer einen eindeutig generierten Bezeichner verwenden können. Wenn die Tabelle einen Ersatz-Primärschlüssel hat (und in einem solchen Fall würden Sie es sicherlich erwarten), sollte dieser Schlüssel dem Benutzer zugänglich gemacht werden oder sollte ein anderes Feld für diesen Zweck verwendet werden?

Ein Grund, den Ersatzschlüssel nicht verfügbar zu machen, besteht darin, dass Sie jetzt keine Vorgänge ausführen können, bei denen die Beziehung zwischen Datensätzen beibehalten wird, sondern die Schlüsselwerte geändert werden, z. B. bestimmte Arten des Löschens / erneuten Einfügens ein anderer, etc.

Der Hauptvorteil beim Anzeigen des Ersatzschlüssels ist die einfache Verwendung eines Felds, das Sie ohnehin haben.

Unter welchen Umständen ist es besser, den Ersatzschlüssel den Benutzern direkt zur Verfügung zu stellen?

design database-design relational-database rdbms surrogate-keys bA
quelle
Ein Teil dieser Frage ist, dass Sie "Benutzer" definieren müssen. Benutzer können Konsumenten einer von Ihnen offen gelegten API oder fleischige Menschen sein. Die Antwort wird nicht für beide gleich sein.
James Snell
1
Fleischige Menschen.
PSR
Jede Situation, in der die Daten unterschiedlich identifiziert werden könnten, sollte eine andere Kennung haben. Wenn sich ein neues System mit Ihren Daten verbindet, erwarten Sie, dass es eine eigene PK hat, und fügen Sie diese Ihren Daten hinzu. Die Sichtbarkeit von "hässlichen Beuteln mit größtenteils Wasser" gilt in diesem Szenario als "System". Meine bevorzugte Lösung besteht darin, die Schlüssel und Zeitstempel (Hinzufügen und Ändern und Löschen) für die Entitäten in einer speziellen Tabelle zu speichern. Auf diese Weise können die Daten einfach verteilt werden.

Antworten:

10

Sie müssen bereit sein für alle Identifikatoren, die Benutzern / Kunden zur Verfügung stehen, die geändert werden müssen. Wenn Sie die Identität einer Zeile in einer Datenbank ändern und diese Änderung auf alle Fremdschlüssel übertragen, müssen Sie lediglich die Daten brechen.

Wenn die Daten keinen natürlichen Geschäftsschlüssel haben, können Sie ein zusätzliches Feld für eine "Geschäftskennung" hinzufügen. Dies sollte für die Prozesse optimiert werden, für die es verwendet wird. Telefontastatureingabe bedeutet nur numerisch. Über das Telefon / verbale Mittel vermeiden Sie ähnlich klingende Symbole (B / D, M / N, etc.). Sie können sogar eine leicht einprägsame Phrase ("grünes Gelee") automatisch generieren lassen.

Dies hat zur Folge, dass das Unternehmen später ändern kann, wie es auf Datensätze verweisen möchte. Die einzige Änderung des Datenschemas besteht darin, entweder eine neue Spalte für diesen ID-Stil hinzuzufügen oder die bereits vorhandenen IDs zu transformieren. Die Änderung wird nicht in der gesamten Datenbank weitergegeben, und Sie haben immer noch eine ID (den Ersatz), die im Laufe der Zeit gültig ist.

Kurz gesagt, ich würde vermeiden, Ersatzschlüssel für Benutzer verfügbar zu machen. Wie aus den Kommentaren hervorgeht, sollten Ersatzschlüssel so gut wie nie geändert werden. Umgekehrt wollen Unternehmen alles ändern. Wenn der Ersatzschlüssel verfügbar ist, ist es nur eine Frage der Zeit, bis das Unternehmen ihn ändern möchte.

Als Randbemerkung, wenn ich sage „Aussetzen“ hier, ich meine den Schlüssel für den Benutzer mit der Erwartung zu geben , dass sie verwenden es direkt (wie in ihrer Auftragsnummer Support zu erhalten ).

Chris Pitman
quelle
5
Diese Antwort macht keinen Sinn. Ersatzschlüssel ändern sich nie, und Sie haben keine Argumente dafür angeführt, dass Sie sie nicht für Benutzer freigeben.
Robert Harvey
1
Sag niemals nie. Was ist, wenn letzteres Design zu einer Rekordkonsolidierung führt? Was ist, wenn Sie Ihre Identität vergrößern und von ihr entfernen müssen?
DougM
3
@DougM: Schreiben Sie dann die Datensätze mit ihrem eigenen Ersatzschlüssel in eine neue konsolidierte Tabelle und pflegen Sie die Originalschlüssel in separaten Feldern in der neuen Tabelle (und in einem Feld, das die Originalquellentabelle identifiziert) als Referenzen, falls erforderlich. Diese Art der Konsolidierung sollte außerordentlich selten sein, und zwar nur aufgrund eines verpfuschten Designs. Wiederholen Sie nach mir: Ersatz. Schlüssel. Noch nie. Veränderung. Deshalb sind sie Ersatz.
Robert Harvey
2
@RobertHarvey Ich bin damit einverstanden, dass sich Ersatzschlüssel niemals ändern sollten, weshalb ich denke, dass sie schlechte externe Kennungen darstellen. Schließlich ein Kunde zu ändern möchten , wie sie auf einen Datensatz verweisen. Zu diesem Zeitpunkt haben Sie entweder Ihr gesamtes System auf unveränderlichen Ersatzschlüsseln aufgebaut, oder Sie haben vorausgedacht und ein Maß an Indirektion zwischen Geschäftskennungen und Ersatzschlüsseln festgelegt.
Chris Pitman
2
@sqlvogel: Würde es die Sache klarer machen, wenn ich den Begriff "systemgenerierter Primärschlüssel" anstelle von "Ersatzschlüssel" verwenden würde? Ich bin damit einverstanden, dass Sie möglicherweise den Algorithmus ändern möchten, der die Ersatzschlüssel generiert, aber dies ändert nichts an ihrer grundsätzlich unveränderlichen Qualität.
Robert Harvey
4

In einigen Fällen werden Ersatzschlüssel erwartet, die für Benutzer sinnvoll sind. Mein Lieblingsbeispiel ist "Bestellnummer". Die Bestellnummer ist nicht wirklich ein natürlicher Schlüssel: Ein natürlicher Schlüssel kann ein Zeitstempel plus Benutzer sein oder mehr, wenn Sie erwarten, dass Benutzer mehr als eine Bestellung innerhalb der Granularität Ihres Zeitstempels generieren.

Trotzdem verstehen und erwarten die Benutzer die Bequemlichkeit einer Bestellnummer. Es gibt keinen Schaden und viel Wert, wenn Sie Benutzer über sie informieren.

Andererseits ergeben einige Ersatzschlüssel für einen Benutzer keinen Sinn. Sicher, meine Krankenkasse hat einen Ersatzschlüssel, der mich anhand meiner Mitgliedsnummer, meines Geburtsdatums, meines Trägers usw. identifiziert, aber das interessiert mich nicht, ich kümmere mich um die Informationen auf meiner Karte (die häufig IDs enthalten) auf meinem Arbeitgeber und sind nicht einzigartig im Universum ... Daher der Ersatzschlüssel bei der Versicherungsgesellschaft).

Alan Shutko
quelle
Wenn ein Benutzer es versteht und erwartet, mit ihm zu interagieren, ist es kein Ersatzschlüssel mehr. Ersatzschlüssel sind so definiert, dass sie keine geschäftliche Bedeutung haben. Nur weil es eine ID-Nummer ist, heißt das nicht unbedingt, dass es ein Ersatz ist. Auch "ein Ersatzschlüssel, der mich anhand meiner Mitglieds-ID, meines Geburtsdatums [...] identifiziert", ergibt keinen Sinn. Sie sagen, dass der Ersatzschlüssel (der keine geschäftliche Bedeutung hat) Sie anhand von Dingen identifiziert, die einen natürlichen Schlüssel bilden könnten?
Kyle McVay
Oftmals erhalten Sie eine Mitarbeiter-ID, sodass Sie im Mitarbeitersystem von anderen Personen mit demselben Namen unterschieden werden. Auf Ihrer Versicherungskarte sind möglicherweise Ihre Unternehmens- und Mitarbeiter-ID aufgeführt. Die Krankenkasse generiert jedoch häufig eine eigene interne ID, die sie systemübergreifend verwenden kann, anstatt den Namen, das Geburtsdatum und die Mitarbeiter-IDs zu verwenden, die sie von Ihrem Arbeitgeber erhält. Sind diese generierten Schlüssel Ersatzschlüssel oder natürliche Schlüssel? Hängt davon ab, wen Sie fragen (überprüfen Sie 2 alternative Definitionen auf de.wikipedia.org/wiki/Surrogate_key )
Alan Shutko
1

Sie sollten einen Ersatzschlüssel nur verfügbar machen, wenn es sich um eine ordnungsgemäß generierte GUID / UUID * handelt. Sequentielle Ersatzschlüssel verfügbar zu machen ist Nummer 4 bei den OWASP Top 10-Sicherheitsproblemen.

* In der Praxis ist es am besten anzunehmen, dass es für diese Zwecke nicht ordnungsgemäß generiert wurde, es sei denn, Sie wissen, dass es von einem kryptografisch sicheren Zufalls- oder Pseudozufallszahlengenerator erstellt wurde.

Peter Taylor
quelle
2
Aus Ihrer Antwort geht nicht hervor, wie eine GUID die Sicherheit verbessert.
Robert Harvey
1
@RobertHarvey - Ich nehme an, weil sie nicht sequentiell sind und daher nicht erraten werden können.
Bobson
1
security.stackexchange.com/q/38777
Robert Harvey
@ Robert Harvey, geklärt.
Peter Taylor
1

Wenn eine Tabelle keinen natürlichen Schlüssel hat, lassen Ersatzschlüssel solche Zeilen zu.

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

Ich würde diese künstlichen Schlüssel anstelle von Ersatzschlüsseln nennen, aber diese Unterscheidung ist für diese Frage nicht wichtig.

Angenommen, es gibt wichtige Daten, die diese Ersatzschlüssel durch Fremdschlüssel referenzieren. Woher wissen die Endbenutzer, welche Zeile aktualisiert werden muss, wenn sie die Ersatzschlüsselwerte nicht kennen?

Mike Sherrill 'Cat Recall'
quelle
Es ist ein wenig widersprüchlich, die Spalte "surrogate_key" zu bezeichnen, aber dann zu sagen, dass es sich um "künstliche Schlüssel anstelle von Ersatzschlüsseln" handelt. Wenn Sie diese künstlichen Schlüssel aufrufen, weil sie keine geschäftliche Bedeutung haben und nur als eindeutige Bezeichner dienen, sollte dieser Schlüssel eingebürgert (verfügbar gemacht) und ein neuer Ersatzschlüssel erstellt werden. Das heißt, benennen Sie den eingebürgerten Ersatzschlüssel in etwas mit geschäftlicher Bedeutung um, machen Sie ihn den Kunden zugänglich und erstellen Sie eine neue ähnliche Spalte, die der wahre Ersatz für interne Operationen ist. Weniger als ideal, aber immer noch besser als eine echte Leihmutter zu entlarven.
Kyle McVay
@KyleMcVay: Das ist kein Widerspruch. Es würdigt die Bedeutung von Leihmutterschaft , deren wesentlicher Gedanke "zu ersetzen" ist. Ein Ersatzschlüssel Ersatz für einen natürlichen Schlüssel. (Codd und relationale Theorie im allgemeinen Gebrauch Ersatzschlüssel in diesem Sinne.) Eine Tabelle , die hat keine natürlichen Schlüssel nicht haben einen Ersatzschlüssel in diesem Sinne. Aber es kann einen beliebigen Wert haben, der anstelle von irgendetwas anderem verwendet wird. Das würde ich einen künstlichen Schlüssel nennen.
Mike Sherrill 'Cat Recall'
Ihre Definitionen sind nicht ungenau, aber ich denke, der Ersatzschlüssel hat über das Wort Ersatz hinaus eine zusätzliche, branchenspezifische Bedeutung erhalten . Wenn Sie einem Kunden einen Schlüssel zur Verfügung stellen möchten, würde ich argumentieren, dass dieser Schlüssel jetzt eine geschäftliche Bedeutung hat. Es wurde eingebürgert und sollte nun als logischer Teil der Einheit betrachtet werden, die es repräsentiert. Nach dieser Logik gibt es keinen freigelegten Ersatzschlüssel. Wenn Sie einen künstlichen Schlüssel freigeben möchten, ist dieser kein Ersatzschlüssel mehr und Sie benötigen einen neuen.
Kyle McVay
0

Mit den Worten des Laien:

  • Ersatzzeichen sollten vor dem Benutzer verborgen sein.
  • Sie sollten dem Benutzer einen anderen Geschäftskandidatenschlüssel zur Verfügung stellen.
  • Wenn kein anderer Kandidatenschlüssel vorhanden ist, sollten Sie die PK anzeigen. In diesem Fall wird die PK jedoch nicht als Ersatz angesehen, da sie keine andere Spalte ersetzt.
Tulains Córdova
quelle
Warum muss die PK angezeigt werden? Ich denke, das ist meine Frage - ob eine automatisch generierte PK ordnungsgemäß als Ersatzschlüssel bezeichnet wird, ist tangential.
PSR
1
@psr Ihre Frage Titel sagt „ Surrogat Schlüssel jemals ausgesetzt werden“. Ich sagte nein. Aber Sie müssen einen anderen Schlüssel zeigen. Wenn kein anderer Schlüssel vorhanden ist, müssen Sie den einzigen Schlüssel anzeigen, den Sie haben. Tangential verdeutliche ich, dass der Schlüssel in diesen Fällen kein Ersatz ist, da er keine andere Spalte ersetzt.
Tulains Córdova
Die Frage ist, ob Sie eine Spalte hinzufügen oder den Schlüssel anzeigen sollen, den Sie haben.
PSR
@psr Ich habe meine Antwort umformuliert, um sie klarer zu machen.
Tulains Córdova
1
Ich halte das für eine materiell unbedeutende Unterscheidung. Wenn Ihre Regel lautet, dass jeder Tisch einen künstlichen Schlüssel hat (welcher meiner ist) und dass nur die künstlichen Schlüssel an Verknüpfungen teilnehmen (was auch mein Prinzip ist), dann die Vorstellung, dass ein Schlüssel ein Ersatz ist, weil andere Schlüssel möglicherweise sein könnten verfügbar ist belanglos.
Robert Harvey
0

Sie sollten ein Feld NUR einem Benutzer aussetzen, der dem Benutzer nützliche Informationen zur Verfügung stellt, entweder direkt oder wenn Sie Fehler melden.

Umgekehrt sollten Sie IMMER "Ersatzprimärschlüssel" verfügbar machen, wenn diese das Hauptmittel zur Identifizierung eines Datensatzes (einfach oder komplex) für eine vom Benutzer durchgeführte Interaktion sind.

DougM
quelle
0

Es sollte keine Rolle spielen, ob Sie die Schlüssel dem Endbenutzer aussetzen oder nicht. Ihre Anwendung sollte die erforderliche Autorisierung durchführen, damit sie beispielsweise nicht durch einfache Kenntnis einer Bestellnummer auf etwas zugreifen können, auf das sie normalerweise keinen Zugriff haben.

Einschränkung: Dies setzt eine webbasierte oder n-Tier-Anwendung voraus, bei der serverseitige Autorisierung möglich / machbar ist. Wenn Sie eine VB-App haben, die SQL direkt ausführt, ist das ein ganz anderes Problem.

GroßmeisterB
quelle
Wie wäre es, wenn Sie keine Datensätze einfügen und löschen können, während die in der Frage erwähnten Fremdschlüsselbeziehungen erhalten bleiben?
PSR
Was hat das damit zu tun, dass der Schlüssel dem Benutzer zugänglich gemacht wird? Vielleicht verstehe ich Ihre Verwendung des Begriffs "Belichten" nicht. Ich gehe davon aus, dass Sie "für den Benutzer sichtbar" meinen.
GroßmeisterB