Should I use a primary key id if table means nothing alone? [duplicate]

Question

I have a table called 'Date Restriction' and it basically holds the following properties:

DayId    : int
DateFrom : datetime
DateTo   : datetime
EventId  : int       // this is a foreign key

Now the way I would access this is to get the event I want and then look at the associated Date Restrictions.

Is it good practise or recommended to add a primary key column to this table if I never have to reference the date restriction alone?

Answer 1

You should always have a primary key. Having a primary key will allow SQL Server to physically store the data in a more efficient manner. A primary key also allows Entity Framework to easily uniquely identify a row.

Look for a natural key across your columns. If a single EventId will only ever have one row in this table, create a primary key on EventId.

If there is not a natural key, add a surrogate key column to your table and make it an identity.

Answer 2

As a database design practice, it is always recommended to have primary keys. Even if your application does not directly reference the DateRestriction Table, having a unique identification for a row will give you benefits not only on the SQL side but it will also allow entity framework to easily map the table (without going through any extra hoops).