>>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...

Is that really 'user friendly' or should it be 'developer friendly'?

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

Yes. Though you need to be extra careful with Chr(0) which is not going to work if the table is also accessed by a Fox 2X system. Some developers do not like to see the ace of spades and a smiley in a field, probably makes them think the table has gone south. I do not have any problems with this.

I recently came across a system with a table containing a Codebook compacted date time stamp that was shared between Fox for DOS and VFP - the chr(0) in one of the rows was causing a nasty bug, took quite a bit to uncover it.