>What about where large number of fields are null? One company uses one field, but theother 20 don't, so for 19 of the companies they have a field that is full of all nulls. Do that for every company, and you have each company with the same table (and a normalized table) but you have 19 fields that are all null but still taking up the space (can't fit as many records into the buffer as a result).
>
>I could keep it as normalized, I would think, if I used the company's name as a primary key, and then joined their customized fields (from another table) to the main table, don't you think?
>
>My boss is definately in your school of thought, but I just think we are taking a huge hit in terms of speed because of the setup. Granted, it would be a hassle and then some to change it all...but if we'd see a 2x jump in speed or something, it might be worth it...
>
>Thus I ask, because I'm not sure when having a few extra fields start to slow things down more then doing a join.
>
>matt

You would definitely waste space if you have unneeded fields.

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.

Hilmar.