2009-06-13 12 views
4

J'ai 2 tables dans ma base de données que j'essaye de créer des entités de Linq2Sql pour. Il y a plus à eux que cela, mais cela est essentiellement ce qu'ils se résument à:Linq2Sql: Puis-je créer des entités avec des relations de clé étrangère sans clé primaire dans les deux tables?

 
Rooms   UserActivity 
--------  -------- 
RoomID   ActivityID 
       RoomID (foreign key on Rooms.RoomID) 

Le tableau UserActivity est essentiellement juste un journal pour les actions d'un utilisateur effectue sur la table des chambres.

Depuis la table UserActivity est utilisée uniquement pour les actions forestières prises, il n'a pas beaucoup de sens (pour moi au moins) pour créer une clé primaire de la table à l'origine, jusqu'à ce que le mappeur Linq2Sql a refusé de faire UserActivity un partie de l'entité Room dans mes entités Linq. Quand je mis en place les entités dans le concepteur Visual Studio, je suis arrivé ces 2 avertissements:

  • Warning 1 DBML1062: The Type attribute 'UserActivity' of the Association element 'Room_UserActivity' of the Type element 'Room' does not have a primary key. No code will be generated for the association.
  • Warning 2 DBML1011: The Type element 'UserActivity' contains the Association element 'Room_UserActivity' but does not have a primary key. No code will be generated for the association.

Ces avertissements me ont amené à créer la colonne ActivityID dans mon tableau tel qu'affiché ci-dessus. Ce que je voudrais savoir, c'est s'il y a un moyen de permettre à Linq2Sql de créer des relations entre mes entités sans avoir de clé primaire dans les deux tables. Si je n'ai pas la clé primaire dans la table UserActivity, les entités peuvent toujours être créées, mais les relations ne sont pas générées.

Est-il possible de faire cela, ou devrais-je essayer de m'assurer que mes tables ont toujours une clé primaire comme bonne pratique générale?

Répondre

3

Toute table qui stocke des données réelles dans votre application doit toujours avoir une clé primaire - dans la plupart des cas, dans les environnements SQL Server, une INT IDENTITY (1,1) sera très bien. Vous n'avez pas besoin de garder une trace de ceux-ci, pas de comptabilité nécessaire, etc. Cela ne vous coûte pas cher, tout à fait facile à faire - je ne vois aucune raison de ne pas avoir de clé primaire, même sur votre table UserActivity.

ALTER TABLE UserActivity 
    ADD UserActivityID INT IDENTITY(1,1) 
    CONSTRAINT PK_UserActivity PRIMARY KEY 

et vous avez terminé! La seule fois où je dirais qu'aucune clé primaire n'est nécessaire est pour des choses comme des tables temporaires lors de l'importation en masse d'énormes quantités de données, ou d'autres scénarios temporaires.

Marc

1

Vous avez besoin d'une clé primaire pour créer des relations. Il est recommandé de toujours concevoir des tables avec des clés primaires, même si vous ajoutez un substitut (identité d'incrémentation automatique).

Questions connexes