ViewModelのデータベースからの自動インクリメント主キー（ID）の表示を防止し、エンドユーザーに表示させないようにするには、ベストプラクティスがありますか？主キーの代わりにViewModelの代理キー
テーブルには、使用できる他の固有のフィールドがあることは知っています。しかし、ユニークなものがあるかどうか分からない場合はどうなりますか？
私はハッシュを作成し、データベースのViewKeyのような名前のカラムに保存することを考えていました。たとえば、テーブルのアドレスです。
ベストプラクティスは、（通常はビジネスキーまたは自然キーと呼ばれる）を使用すると、ユーザーに表示され、意味のある事業ドメインで使用可能であること、キーを必要とするということです。そのようなキーを実装せずにユーザーに表示させる場合、ユーザーがデータベース内の情報を識別し、現実世界で正しく使用することを期待するにはどうすればよいですか？
キーがプライマリであるかどうかに大きな違いはありません。重要なのは、それらがnullableではなく、データベース内の一意性制約で強制されることです。
分析と設計の一環として適切なキーがすでに特定されていない場合は、それを実行します。ビジネス要件が決定要因でなければなりません。明らかに、単一のサイズに適合するすべてのソリューションはありません。
多分私は質問を誤解しています。エンドユーザにDBフィールドを表示したくない場合は、しないでください。エンド・ユーザーがDB表に直接アクセスできるようなツールを使用していますが、表示されるフィールドを制御することはできません。
「このようなオートナンバーフィールドを使用しないでユーザーがどのようにレコードを識別できますか」という場合は、テーブルに何らかの自然キー、つまりソーシャルセキュリティ番号や標準国コードなど、コンピュータ外の世界に存在する識別子がある場合は、それをプライマリキーとして使用することができます。自動番号。一意であることが保証された現実の価値がない場合は、自動番号フィールドやGUIDなどの識別子を作成する必要があります。内部使用のための識別子を作成する場合は、それをユーザーに表示し、ユーザーがレコードを識別するために使用できるようにすることもできます。必要がない限り「内部識別子」と「外部識別子」を作成するのはなぜですか？自動番号フィールドが受け入れられない理由がある場合 - 識別子には小切手などが必要です - 次に、受け入れ可能な識別子を作成し、それを内部的および外部的に使用します。
ナチュラルキーが内部キーにとって不適切な選択肢である場合がありますが、最も一般的な理由は、キーが長すぎてインデックスやルックアップが大きく遅くなるためです。それが「内部鍵」と「外部鍵」を持つ唯一の理由です。