Ich frage mich, ist es schlechte oder gute Idee, Auto-Inkrement-Primärschlüssel als Business-Entity-ID wie Partner Id oder Account Number zu verwenden?Ist es eine schlechte Idee, den Primärschlüssel einer Datenbank als Business Object Identifier zu verwenden?
Auch, welche Fallstricke kann ich konfrontieren, wenn ich diesen Ansatz wählen werde?
Ich glaube nicht, dass alle die gleiche Meinung teilen, aber ich denke, es ist eine schlechte Praxis. Die Weitergabe von IDs an den Benutzer als "Schlüssel" ist meiner Meinung nach aus einer Reihe von Gründen schlecht:
In unseren Produkten verwenden wir immer einen 'natural key', neben dem Primärschlüssel, ein Schlüssel, der von Menschen verstanden wird.
Wenn kein für den Menschen verständlicher natürlicher Schlüssel verfügbar ist, z. B. wenn es sich um eine Protokolltabelle handelt, können Sie zu einem künstlichen Schlüssel zurückkehren.
Ich glaube, dass das OP fragt, ob es eine gute Idee ist, es als seine PK zu verwenden, basierend auf dem nachfolgenden Kommentar, den sie gemacht haben. Nachdem ich mit Benutzern von Anwendungen in einer Rolle als Supportentwickler seit vielen Jahren zusammengearbeitet habe, habe ich festgestellt, dass Benutzer dazu tendieren, sich ziemlich schnell an einer ID-Nummer zu orientieren. Wie in "Hey wirst du @ Record Nummer 14567 aussehen und mir sagen, ob die Beschreibung verwirrend ist?". Mein Vorbehalt ist, wenn eine GUID als PK verwendet wird, wenn das der Fall ist, dann ist ja die Verwendung eines natürlichen Schlüssels eine großartige Idee (aber ich würde niemals die tatsächliche PK dem Benutzer in diesem Fall zeigen). – MER
@mer: Ich rate absolut nicht, das PK zugunsten eines nk zu ersetzen. Das ist sogar unmöglich. –
Ich entschuldige mich für meine Unklarheit. Ich habe nicht vorgeschlagen, dass Sie ihm sagten, er solle einen natürlichen Schlüssel als PK benutzen (obwohl es möglich ist, http://www.agiledata.org/essays/keys.html (Punkt 2), es ist nur eine schlechte Idee) . Mein einziger Punkt sollte sein, dass die Benutzer meiner Erfahrung nach nicht auf die Idee kommen, auf die Nummer zu verweisen, aber dann schnell die generierte Nummer als primären Bezugspunkt für einen bestimmten Datensatz in einer Anwendung verwenden (Datensatzbedeutung) alle gesammelten Daten, die in einer Anwendung angezeigt werden, wie z. B. eine Kontonummer oder eine Datei- oder Projektnummer usw. – MER
Es gibt mindestens drei wünschenswerte Eigenschaften, die Sie bei der Auswahl oder dem Entwurf von Schlüsseln beachten sollten: Einfachheit, Stabilität und Vertrautheit. In der Praxis fällt es den Menschen oft leichter, sich an Wörter und Buchstaben als an Zahlen zu erinnern, und deshalb sind alphanumerische Kennungen im Allgemeinen häufiger als numerische Kennungen (Beispiele für alphanumerische Kennungen: Autokennzeichen, Flugnummern, Sitzplatzreservierung) Nummern, Landes- und Ländercodes, Postleitzahlen, E-Mail-Adressen). Es gibt Studien und annewdotale Beweise, die die Idee unterstützen, dass alphanumerische Schlüssel brauchbarer sind als Zahlen allein. Auch alphanumerische Kennungen können oft kürzer als numerische sein. Auf der anderen Seite sind sequentielle Nur-Zahlen-Identifizierer für einige Anwendungen sehr üblich (z. B. Rechnungsnummern, Bankkontonummern). Daher schlage ich vor, dass Sie sich bei der Bestimmung dieser Dinge an den Bedürfnissen Ihrer Nutzer orientieren sollten.
Beachten Sie, dass DBMS-Engine-Sequence-Generatoren oft mit Einschränkungen versehen sind, die sie für einige Anwendungen ungeeignet machen. Zum Beispiel ist es möglicherweise nicht einfach, sie zu aktualisieren oder sie in einer verteilten Datenbankarchitektur zu verwenden. Eine andere häufige Einschränkung ist, dass nur eine "automatisch inkrementierende" Spalte pro Tabelle erlaubt sein darf, was ihre Verwendung als Geschäftsschlüssel ausschließt, wenn Sie auch einen Ersatzschlüssel für die gleiche Tabelle wünschen.
weist darauf hin, dass ich vorher keinen Platz hatte, um Kommentare zu kommen. Autoinkrementierte Primärschlüssel können ein Problem in Anwendungsentwürfen sein, bei denen die Daten in mehreren Datenbanken eindeutig sein müssen ... in diesem Fall auf eine GUID als PK zurückgreifen. Allerdings werde ich hinzufügen, dass meine anekdotische Erfahrung mit tatsächlichen Benutzern mit tatsächlichen Anwendungen war, dass sie glauben, ein Name wird einfacher, wenn zunächst gefragt, aber innerhalb weniger Wochen nach der Verwendung der Anwendung beziehen sie sich auf den Ersatz Schlüsselwert viel häufiger als die Name, (auch vollständig numerische Werte). – MER
Ich glaube nicht, dass Sie sagen, die Verwendung von IDs oder Zahlen ist eine schlechte Idee für sich. Es kommt darauf an. Oft sind IDs und Zahlen einfach perfekt. Fragen Sie sich selbst: An welchen anderen Schlüssel haben Sie sonst gedacht? Und, wäre das besser? Ich denke nicht, dass es auch wesentlich besser ist. Ein Trick mit Zahlen ist, nicht mit 1 zu beginnen, sondern eine ID mit 1000000 beginnen zu lassen, die andere mit 20000000 usw. – tvCa
@tvCa: Natürlich meine ich nicht ID oder Zahlen selbst. Ich meine auto inkrementelle ID als Teil der datenbankspezifischen Informationen. – Vokinneberg
@Vokinneberg bitte klären Sie Ihre Frage. Wenn Sie "als Entitätsbezeichner" angeben, ist dies keine eindeutige Aussage. Die meisten von uns würden das Geschäft als Kunden betrachten. Aber Ihr Kommentar schlägt vor, dass Sie meinen, dass es ideal für den Primärschlüssel für den Tisch ist. Und die Antwort auf diese Frage ist, es ist definitiv eine gute Passform für eine PK, wenn Sie es als eine automatisch inkrementierende Spalte und die PK definieren ... solange Sie keine GUID generieren ... Ich würde das auch hinzufügen einem Kunden eine Kontonummer zu zeigen, die ein automatisch inkrementierter Wert ist, ist in Ordnung ...solange es keine GUID ist – MER