In Rat-holes of Lost Time [Rat-Holes of Lost Time ], I thought out loud about software development and how the resulting software product may or may not be of any value. In SEI terminology [view_qm ], this is Need Satisfaction. Sometimes I call it Solving The Problem ™.

I tried to distinguish two …

Much of software development is best described as "problem-solving". Much of the rest, BTW, is knowledge capture.

When we look at the time spent on problem solving we can see four potential outcomes.

1. Time is spent producing a viable solution to the actual problem.
2. Time is spent producing a non-solution …

In it, Bruce Silver recollects process reengineering gurus who warned "Don't pave the cowpaths!". Presumably because the cow path was a random walk all over the pasture land, and wasn't the most efficient course.

However, anyone who was watched cows at work will tell you that the cow path is …

In principle, stating a problem is a trivial exercise: someone can't do something. It can be made wonderfully complex, however. The root cause of the complexity could be a fundamental unwillingness to state the problem without including technology hints like "database" or "hierarchy" or "project management" or "change control".

"Polymorphism is nice as well, although I can't grok (yet) why this is necessarily not part of non-OO things. I'm not clear that it goes with the strong binding of state and method in a class."

Polymorphism isn't necessarily part of OO. Python actually has polymorphic functions outside of class …

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 …