Home/ Questions/Q 83913
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T21:50:54+00:00

When designing a lookup table (enum) in SqlServer 2005, if you know the number

  • 0

When designing a lookup table (enum) in SqlServer 2005, if you know the number of entries will never get very high, should you use tinyint instead of int? I’m most concerned about performance, particularly efficiency of indexes.

Let’s say you have these representative tables:

Person ------ PersonId int  (PK) PersonTypeId tinyint  (FK to PersonTypes)

and

PersonTypes ----------- PersonTypeId tinyint PersonTypeName varchar(50)

The obvious factors are data size and coding hassle. When we get to 100 million rows in the person table, we’re storing 300 million less bytes with tinyint as opposed to int, plus the space taken up by our indexes. Not a huge amount of data, but significant if the design decision is applied to dozens of big tables. The coding hassle, of course, comes from all those casting problems back in the ASP.NET C#/VB code.

If we set aside those two issues, what else comes into play? Will queries be much more efficient due to the decreased size of the index pages? Or is there some sort of padding that happens that will just negate the benefits? Any other gotchas?

I’ve always just used ints personally, but I’m considering tinyint for an upcoming redesign/migration effort on some huge tables, so I’d love to get some advice.

[Edit]

After experimenting with this, the coding hassles I anticipated turned out to be a non-issue. Changing from int to tinyint hasn’t resulted in any casting problems at all.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. The narrower a table (or index node entry) is, the more records (or index nodes) can fit on a single IO page, and the fewer physical (and logical) reads IO operations are required for any query. Also, the more index nodes there are on a single page, the fewer levels there may be in the index, from root to leaf level, and if by making a table narrower you pass the threshold where the index can be one level smaller, this can have a dramatic effect on perforamnce.

    If by switching to TinyInt you change your table from 200 bytes wide to 197 bytes wide, it probably won’t make any difference… But if you change it from 20 bytes to 14, (say you have 2 ints in there), then it could be dramatic…

    • 0