Home/ Questions/Q 7950133
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-04T02:10:32+00:00

I have a simple classic example Products -> ProductCategories <- Categories On the one

  • 0

I have a simple classic example 

Products -> ProductCategories <- Categories

On the one hand, some OR/M’s (such as Linq2SQL) doesn’t want generate navigation property “ProductCategories” in “Products” without PK, on the other hand, this is only link table?
If this table contains PK – ok, I’m able to preform all CRUD operations, otherwise – also true (I may use complex key ProductsId + CategoriesId to manipulate each row)

P.S. I’m used to create constrain like
ProductCategories.ProductsId + ProductCategories .CategoriesId is unique

So, which approach more useful from performance perspective?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would virtually always recommend the use of a PK. For one thing, it is required for normalization. For another, the clustered index (not technically the same as the PK, but by default the clustered index is defined on the PK) will generally help with performance, though how much depends heavily on the usage characteristics. And, as you noted, many ORMs and other frameworks that work with a SQL Database expect a PK for structural purposes.

    Depending on your situation, simply creating the PK on both columns of a link table often makes sense, though I have worked with one framework that expected every table to have an integer Id column.

    • 0