Re: Theory IS Practical.

Laconic2 wrote:

> I'll admit that I haven't read much of Date. When I came up to speed on
> relational databases, in about 1983, I never heard of Date. And later, I
> was too busy with practical matters to bother much with Date.But I do like
> some of the shorter things he's written.
>
> And my favorite is this: "Theory is practical."
>
> I'm more of a practical type myself, rather than a theoretician. And I
> have
> little use for dogma. If my karma and your dogma get into a fight, my
> karma is going to run over your dogma.
>

I am glad you brought this up. I have been meaning to ask the question "what is the relationship between theory and practice in computer science?" It seems to me that there are some very large unstated assumptions in this group about this relationship, which perhaps should come to light.

Consider the following three relationships:

1. math -> physics
2. physics -> engineering
3. math -> engineering

The first well-known relationship is that math is the language of physics. Mathematical systems provide the framework for physicists to do their jobs. Great.

For the second relationship, define "engineering" as simply "building something to satisfy human motives." The engineer uses knowledge of the physical world to build things like bridges that serve human purposes without falling over and killing the people trying to use them.

Finally we have the third relationship, which I posit is not valid but which we see here. This relationship jumps straight from free-floating axiomatic systems to bridges. A simplified example of this jump is "The RDM requires sets instead of bags, and your system allows duplicate indistinguishable row, ergo your system is *bad* *engineering*." Huh?

The mismatch is because the axiomatic system, RDM, aims only to remain internally consistent (what mathematicians want), while the database system aims to satisfy human motives.

This is not to say that RDM is irrelevant. It's appeal is that it gives a framework for determining data correctness, which satisfies a human motive. But if it is not complete (hierarchies?) then we will end up choosing to combine it with other models to enhance our ability to store information about the world.

>
> In places where designers, for better or for worse, have not wanted to
> follow 3NF, the programming manager usually says, "yeah, but my people
> are
> real smart. They can program around those anomalies." And sometimes the
> programming manager is RIGHT, by golly! But sometimes the programming
> manager is WRONG, by golly!

Mostly the programmers are so smart that they get to work through the night, on the weekends, and over the holidays. No thanks, I don't want to be that smart anymore.

>
> I think that someone who only learns how to make a data design conform to
> 3NF has only learned half of the theory. What you also need to learn is
> what can happen if you DON'T follow any given normalization rule. Then,
> at least you know what you are going to have to program around.

How about the third half? This is information that cannot be stored in a 3NF database such that information meaningful to human beings can be retrieved without procedural code, such as hierarchies or the bipartite matching problem?

I find myself coming back over and over to the issue of derived data, such as extended price = price * qty. If I am trying to satisfy a mathematical theory, I will leave this out, but if I am trying to satisfy human motives of convenience and correctness, I will find a way to store it on save so that downstream users have a better time of it.

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me