>Others have suggested vertical or horizontal partitioning - personally I prefer temporal horizontal. Digressing, I think that's a great phrase, makes me think I'm a rocket scientist (where's my white laboratory coat - with some unrecognizable thing sticking out of the top pocket).
>
>Anyways, back to the matter at hand. I would look in particular at fields with a limited range of values that are disproportionate to the available range. Take dates for example (and I admit the following is rather contrived). Say you have a date field where the dates are all within 10 years of each other and that is the maximum separation – anything greater than ten years might be considered erroneous.
>
>10 years * 365.25 days = 3,652.5 possible values.
>
>With only 2 bytes (16 bits) you can have 65,536 possible values. It is more convoluted but you can use 2 bytes to span dates covering a 179 year period. A 75% space saving over the 8 byte size of a date field. You sacrifice the ability to just browse the field (unless you use a udf), but I like to think of it as data security (very mild encryption).

Temporal Horizontal Partitioning! I think you win the techspeak obfuscation award of the month!

I get the idea, but I think I would simply have a second table of dates to link to the first for my queries to make the whole thing more 'user friendly' - linked together via an integer key (which appears to be the most economical space-wise) or an even more economical single or dual byte key...

What field type would I use for that - C(2)?