>>You would definitely waste space if you have unneeded fields.
>
>Yes, that was sort of the crux of my question. The more space you waste the bigger the table. The bigger the table the slower your operations. But, joins are rather costly, so...
>
>>As to the performance, I think the time it takes to execute a query will depend mainly on the number of records retrieved, and (especially for a not-very-optimized expression), the total number of records. But you might want to do some speed tests to confirm whether the total recsize() significantly affects the time it takes for a query, for instance.
>
>Yea, I didn't want to have to dig out my equations, but I guess i'll have to do it anyway.

What equations?

A speed test basically consists of something like:

StartTime = seconds()
DoOption1()
? "Time taken for option 1: seconds() - StartTime

StartTime = seconds()
DoOption2()
? "Time taken for option 2: seconds() - StartTime

Instead of DoOption1() and DoOption2(), you can directly insert a series of commands whose speed you want to test.

Consider the following points:

Accesing the table a second time may be faster than the first time, because of cache, giving an overly optimistic impression for the second option. It is therefore convenient to repeat the speed test more than once.

If the time taken for something is only a few seconds or miliseconds, you may want to repeat the commands in a loop.

HTH, Hilmar.