The "correct" answer is to fully normalize the design and get away from a mixed bag of columns and nulls. The MESS is bad from every perspective, except query performance. A semi-normalized design that separates the STATE CHANGES from the ESSENTIAL DEFINITION is an optimal design in many respects.

Here …

Experimental results depend on details of the database server and the data model used. Actual application software may have other confounding problems that make these results less dramatic or more dramatic when applied to a existing application design.

I compared three table designs described in a previous posting Normalization Experiment …

Fragmentation & similar is sometimes a storage problem in I/O generated, vs. the gross space consumed. This distinction didn't leap out at me.

Performance degradation and storage expansion are closely related, but only for certain kinds of queries. Full table scans are penalized by sparsely used storage. Individual row retrievals …

The open question is "What is the cost of fragmentation?"

The cost has some absolute components and some relative components. Since fragmentation is difficult to avoid except through grotesque over-allocation of space, the issue is to control fragmentation through normalization. A more important pair of questions, then, are these:

1. What …

"How do we prevent storage fragmentation and the associated slow-down ?"

Why prevent ?

This is hard to respond to. The ounce-of-prevent-pound-of-cure didn't resonate with the reviewer. What would resonate? An in-depth discussion of the "prevention is an investment with an indefinite period of return and correction is an ongoing cost" doesn't …

Perhaps this is heresy. Perhaps it merely shows that the orthodox may be focused on short-term delivery, not long-term value.