Re: the relational model of data objects *and* program objects

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Wed, 13 Apr 2005 12:48:03 -0400
Message-Id: <05vvi2-sb8.ln1@pluto.downsfam.net>

erk wrote:

>>
>> A column like extended=price*qty violates 3rd normal  form and "does

> not

>> belong", hence my comment later in my post that pure database

> theorists

>> will throw away data to preserve a theory.

>
> "Extended" isn't data. It's a function, or calculation. "Throwing it
> away" is meaningless, since it can be produced at will. Why the need to
> "store it in a column," when it needn't have a "physical location" at
> all? I'm very confused.

Let's cut this up a piece at a time:

> "Extended" isn't data.

No? My customers are not mathematicians. To us ignorant rubes it is data as surely as the price and item code are data. Given a choice between a "theory" that provides no guidance for real needs, and a practice that does, I say the practice is the better theory.

> It's a function, or calculation.

Then the meta-data must include its definition:

http://www.secdat.com/dev/atomic.html#bdfd5c37c61ad678db5a74004d3fc58e

> "Throwing it
> away" is meaningless, since it can be produced at will.

I am unsure of what real world experience you have had but when anybody uses the terms "at will" I suspect that:

1. They have never gone out of the classroom or worked on a complex system
2. They have never completed a life-cycle and had to live with the consequences of their design trade-offs, or
3. They have been kept insulated from the cares of downstream users,
4. They lack a certain humility that would allow them to detect any of the above three elements in their experience

All I can say is try with 750+ tables, 10,000+ domains, calculated prorations, calculated aggregrates (including fun ones like weighted averages). In fact, perhaps I can put you in touch with a shop I know, they'd love to find out how to produce this stuff "at will".

> Why the need to
> "store it in a column," when it needn't have a "physical location"

To be fair, I did imply heavily that it would be stored in a column, what I should have made more clear is that it should be defined as if it were a column, and it should be accessible via SELECT as if it were, keeping in mind that implementation is always another story.

>

>> What interested me in the OP was my own question: what theory
>> guides the definition, generation, and protection of automoated data?

>
> I think there are many. Unfortunately, the interesting ones were
> developed and discussed decades ago, before the demand for programming
> drove explosions of languages, "framework", and semi-trained
> developers.

Name two. I love a good read.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

Received on Wed Apr 13 2005 - 11:48:03 CDT