2

ASP.NETとEntityFrameworkを使用してWebサイトを作成しています。私は現在、多対多の関係のマップテーブルを持っています...たとえば、ユーザーとサッカーチームを考えてみましょう。それで：

ユーザー
チーム
UserTeams

パート1：マップテーブルの主キーに複合キーを使用するのがベストプラクティスですか？言い換えると：

UserTeamsテーブル
PKUserIdPK TeamId PreferenceId
_ _

パート2：注意点は私も別のテーブルを持っているということです。これを「UserTeamPredictions」と呼びましょう。これは、特定のチームの各年のユーザーの予測を保存します。そのテーブルには、マップテーブルを指す外部キーがあります。したがって、次のようになります。

UserTeamPredictionsテーブル
PKUserTeamPredictionIdFK UserId
FK TeamId Prediction PredictionYear
_

これはEntityFrameworkで正常に機能しているようですが、Telerikのように使用しているサードパーティのコントロールでリレーションシップを参照するときに問題が発生しました。理想的なデータ設定ではないかもしれませんが、データバインディングなどを使用してコードで操作しやすいように、テーブルの構造/関係を変更する必要がありますか？

変更は、整数の主キーをUserTeamsマップテーブルに追加し、UserTeamPredictionsテーブルが現在のように複合キーを介してではなく、キーを直接参照できるようにすることです。

UserTeamsテーブル
PKUserTeamIdFK UserId
FK TeamId PreferenceId
_ _

UserTeamPredictionsテーブル
PKUserTeamPredictionIdFK UserTeamId Prediction PredictionYear
_

どう思いますか！？

4

2 に答える 2

4

変更する必要があります。「自然キー」に関する議論のための検索スタックオーバーフロー-特にエンティティ生成を使用する場合は、代理キーの方が優れていることはほぼ一般的に認められています。ナチュラルキーまたはコンポジットキーは、一般にエンティティフレームワークスタイルのDALレイヤーではうまく機能しません。たとえば、LightspeedとSubsonicはどちらも、PKとして単一の一意の列を持っている必要があります...現在のバージョンのLightspeedは、列が「Id」と呼ばれることを主張しますが、次のバージョンは変更されます。

于 2009-07-23T21:06:38.240 に答える
2

私はそうしないことを選びます。代理キーを使用して、UserId列とTeamId列に一意のインデックスを配置します。コンポジットキーが2つ以上あると、本当にうんざりします。コンポジットキーとサロゲートキーを混在させるのではなく、可能な限り、すべてのサロゲート、つまり意味のない自動インクリメントキーを使用することにします。

これには、結合で優れたパフォーマンスが得られるという利点があり、スキーマを参照しなくても、特定のテーブルのキー（テーブル名+ ID）を常に知っていることを意味します。一部のORMツールは、複合キーではなく単一列でのみ適切に機能します。

于 2009-07-23T21:05:22.330 に答える