views:

40

answers:

3

The table I am working on has a primary key which is essentially a version number. A couple of examples of the version number are below:

1.0.0.0
1.1.2.24

Varchar seemed the most obvious choice to me, but I'm looking to set the primary key as a clustered index - I have read on SQL performance sites that you should avoid using varchars in clustered primary keys due to paging issues.

Given the version number is of variable length, what would therefore be the most appropriate datatype for the column?

This database I'm working on is running SQL Server 2005.

Thanks for your help.

+3  A: 

Well, you could always use four INT fields - MAJOR, MINOR, RELEASE and BUILD - together, those are 16 bytes like a GUID - not too bad.

The only drawback to this approach is that if you need to reference this table in a foreign key constraint, you'll have to join on all four tables, typically.

I wouldn't use VARCHAR - INT is better (typically faster). Also, due to the variable nature of VARCHAR, things can get a bit messy (VARCHAR fields can grow and cause all sorts of issues, while an INT always stays 4 bytes).

The other quite popular option would be to have those four fields for the actual version, and an additional surrogate VersionID INT IDENTITY for optimal clustered key performance.

marc_s
Thanks for the further clarification on the foreign key. That would certainly be a problem with the joins.
Chris
Went with 4xint to describe versioning, and the VersionID INT IDENTITY as the clustered key. Thanks again.
Chris
+2  A: 

You could introduce a surrogate key (e.g. an IDENTITY int value) and place a unique constraint on the version number column.

Or it may be that the performance issues aren't a significant overhead in your situation, and you can keep the version number as a primary key.

Damien_The_Unbeliever
This is looking quite good, considering the need for the table to be referenced in foreign keys. A combination of this and using int for the MAJOR MINOR RELEASE and BUILD elements may work out.
Chris
A: 

How strict is the format requirement? If it must be "1.0.0.0" then you really only have varchar and char as options --- but that's only the beginning of your problems ("1.0.0.10" will sort before "1.0.0.2")

If you can force a fixed size, say "001.000.000.010", than you could use a char(15) field which should your problems.

James Curran
Thanks - I'd considered the char route, but its far heavier than the IDENTITY int route in the child tables.
Chris