Domanda

I have to create a new table "holidays" into a a SQL Server 2005 DB.

first option:

ID Int **PK**
CustomerId nvarchar (10)
HolidayDate Smalldatetime
Description nvarchar (50)

second option:

CustomerId nvarchar (10) **PK**
HolidayDate Smalldatetime **PK**
Description nvarchar (50)

I think that tipically I will need only to do some queries with join on HolidayDate and CustomerId.

I would be more focused on the latter, because I would have a field less, and it appear 'logically' better to me, even if I have to worry about not insert duplicate records.

What do you think?

Pileggi

È stato utile?

Soluzione

Traditional database design recommends (strongly) that your PK should be a value that has meaning within the DB (an Int, auto-number or something equiv) and not something meaningful to users (such as dates) because meaningful values tend to result in PK collisions and awkward validation logic. Things are much simpler if you stick with the recommended/classic approach.

Sometimes, a complex key may seem like a better approach, but you don't usually gain much. However, you usually do incur complexity.

So, stick with option 1 and maybe apply an index to represent option 2 instead of a PK.

Altri suggerimenti

You need to use the int key. The reason is simple. Holidays are not confined to a single date. There are multiple days in Hannukah. Ramadan's a month long. So even in your first answer you need to update the schema to have a start date and end date

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top