デスクトップアプリの「ユーザー」/「役割」テーブルの代理キー？目的は何ですか？

Question

C＃/ .NET WinForms/Desktopアプリケーションにセキュリティを追加する必要があります。私はOracle DBのバックエンドを使用しています。

テーブルは単純です：ユーザー（ID、名前）、役割（ID、役割）、ユーザーロール（ユーザーID、役割ID）。

Windowsのアカウント名を使用してUserテーブルにデータを入力しています。ロールテーブルは今のところ単に「管理者」、「スーパーユーザー」、「基本ユーザー」...

私はこれらの名前を制御しない場合でも2人で同じWindowsアカウント名を持つことはできませんでした管理（netopsは、なぜ私はそれを管理する必要がないので、私はWindowsアカウントを使用したい;））。ロールテーブルの場合、私は再び重複価値を持つべきではありません - 私は入力を制御し、3つしかないでしょう（1年以内に戦術アプリがなくなる）。 UserRoleは、ユーザーとロールの多対多の関係を表すための結合テーブルであるため、誇張されたキーは正当化されません。

簡単な質問 - なぜユーザーとロールテーブルで「ID」（int）を使用するのが難しいですか？ここでポイントや利点は？これは「私はいつもそうしました」というものですか？それとも、私はしばらくのうちにこれをやっておらず、その理由を忘れていますか？

Answer 1

名前変更 - 主キーの値は変更できません。 Abigail SmithはAbigail Jonesになり、ユーザー名は変更されますが、サロゲートキーはどこでも変更をカスケードしないように保護します。

サロゲート・キーを使用していても、一意でなければならない列または列の組み合わせがある場合は、一意の索引を使用してその列を適用します。とにかくuser.name列とrole.role列の索引が必要になる可能性が高く、一意の索引はスペース効率が良く、有用なメタデータをオプティマイザに提供します。代理キーを持っていても行を一意に識別する別の列の組み合わせがない場合は、エンティティ定義の権利があるかどうか再度確認してください。

注意してください。特にアクセス・パスの少ない非常に狭い表の場合は、索引構成表を使用できます。 Oracleはプライマリ・キーの索引構成表のみを許可しますが、一意キー列に対して外部キーを許可します（ユニーク索引ではなく、一意制約によって適用される場合）。

一意のIDが一意のインデックスによって強制され、ORMによってPKとして処理され、外部キー関係の親として使用されるが、主キー（定義されているDB内の）は、ロールオーバ名/ユーザー名/何であれ、それを索引構成表のドライバとして使用したいからです。

Answer 2

サロゲートキーはintersection tablesに必要ですが、ここではそうするには、いくつかの理由がありません。

• 一貫：すべてのテーブルには、単一の人工的なキーを持っている場合、あなたは常にキーの名前を知っていますあなたはテーブル名を知っています。
• 使いやすさ：1つのキーの意味は、ONとWHEREの句が短く、エラーが発生しにくいことを意味します。
• 相互運用性：一部のORMsは、単一の主キー列を持つ表でのみ機能します。