Ersatzschlüssel in ViewModel anstelle von Primärschlüssel

Question

Gibt es eine bewährte Methode, um zu verhindern, dass Primärschlüssel (IDs) der Autoincrement-Datenbank aus der Datenbank im ViewModel angezeigt werden, damit sie für Endbenutzer nicht sichtbar sind?

Ich weiß, dass es andere eindeutige Felder auf dem Tisch geben kann, die verwendet werden könnten. Was ist, wenn es nicht sicher ist, ob es einen einzigartigen gibt (oder bleibt)?

Ich dachte daran, einen Hash zu erstellen und speichern Sie es in einer Spalte wie ViewKey in der Datenbank. Zum Beispiel in der Tabellenadresse.

Answer 1

Am günstigsten ist es, dass Sie die Schlüssel müssen, die für Benutzer sichtbar sind und die sind sinnvoll und gut im Business-Bereich (in der Regel Geschäftsschlüssel oder natürliche Schlüssel genannt). Wenn Sie solche Schlüssel nicht implementieren und für Benutzer sichtbar machen, wie können Sie dann erwarten, dass Benutzer Informationen in der Datenbank identifizieren und in der realen Welt korrekt verwenden?

Es macht keinen großen Unterschied, ob Schlüssel primär sind oder nicht. Was zählt ist, dass sie nicht NULL-zulässig sind und mit Eindeutigkeitsbeschränkungen in Ihrer Datenbank erzwungen werden.

Wenn Sie im Rahmen Ihrer Analyse und Ihres Designs noch keine geeigneten Schlüssel identifiziert haben, dann legen Sie die Zeit dafür fest. Geschäftsanforderungen müssen der entscheidende Faktor sein. Es gibt offensichtlich keine einheitliche Lösung für alle.

Answer 2

Vielleicht verstehe ich die Frage falsch. Wenn Sie dem Endbenutzer kein DB-Feld anzeigen möchten, dann ... nicht. Verwenden Sie ein Tool, mit dem Endbenutzer direkt auf Ihre DB-Tabellen zugreifen können und Sie nicht steuern können, welche Felder angezeigt werden?

Wenn Sie meinen, "Wie kann der Benutzer einen Datensatz identifizieren, ohne ein solches Autonummernfeld zu verwenden?" Wenn die Tabelle einen natürlichen Schlüssel hat, dh eine Kennung, die in der Welt außerhalb des Computers existiert, wie eine Sozialversicherungsnummer oder ein Standard-Ländercode oder was auch immer, dann können Sie diesen als Primärschlüssel verwenden und brauchen keine Auto Nummer. Wenn es keinen realen Wert gibt, der garantiert eindeutig ist, müssen Sie einen Bezeichner erstellen, z. B. ein Feld für die automatische Nummerierung oder eine GUID. Wenn Sie einen Bezeichner für die interne Verwendung erstellen, können Sie ihn auch dem Benutzer anzeigen und dem Benutzer ermöglichen, ihn zur Identifizierung des Datensatzes zu verwenden. Warum sollten Sie eine "interne Kennung" und eine "externe Kennung" erstellen, es sei denn, Sie müssen dies tun? Wenn es einen Grund gibt, warum ein Auto-Nummer-Feld nicht akzeptabel ist - Identifikatoren müssen Prüfziffern oder Ähnliches haben - dann erstellen Sie einen akzeptablen Identifikator und verwenden Sie ihn sowohl intern als auch extern.

Manchmal ist der natürliche Schlüssel eine schlechte Wahl für einen internen Schlüssel, der häufigste Grund ist, weil es zu lang ist und Indizes und Suchvorgänge groß und langsam machen würde. Das ist der einzige Grund, warum ich einen "internen Schlüssel" und einen "externen Schlüssel" sehe.