在使用Linq to SQL时使用多列(复合)主键是否有益? [英] Is it beneficial to use multicolumn (composite) primary keys when using Linq to SQL?

问题描述

在使用Linq to SQL时，对多对多关系表使用多列(复合)主键是否有益?

Is it beneficial to use multicolumn (composite) primary keys for a many to many relationship table when using Linq to SQL?

还是应该只将Identity列添加为非集群主键并适当地索引FK列?

Or should I just add an identity column as a non-clustered primary key and index the FK columns appropriately?

推荐答案

不是LINQ问题.如果您的架构需要它们，请使用它们.如果您不这样做，请不要.无论哪种方式，LINQ都能很好地处理您的架构.

Not a LINQ issue. If you need them for your schema, then use them. If you don't, don't. Either way, LINQ will handle your schema just fine.

LINQ to SQL不能很好处理的一个领域是用于连接多对多关系的多列/键映射表，但是我不会说这严格属于您要解决的问题.您仍然可以在LINQ内的映射表上执行CRUD操作，但是LINQ无法遍历多对多映射表所呈现的关系. (LINQ适用于一对一和一对多表.)

One area that LINQ to SQL doesn't handle well are multy column / key mapping table that are used to connect a many to many relationship but I wouldn't say this strickly falls under the category that your question addresses. You can still perform CRUD operations on a mapping table within LINQ but LINQ cannot walk the relationship presented by a many to many mapping table. (LINQ works fine with one to one and one to many tables.)

我不能谈论任何有关实体框架的问题，但是，如果EF遇到多列/多键表的任何问题，我将感到非常惊讶.

I can't speak to any issue with the Entity Framework but again, I would be very surprised if the EF had any issues with multi-column / multi-key tables.

这篇关于在使用Linq to SQL时使用多列(复合)主键是否有益?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！