Re: the relational model of data objects *and* program objects
Date: Wed, 13 Apr 2005 12:48:03 -0400
Message-Id: <05vvi2-sb8.ln1_at_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:
- They have never gone out of the classroom or worked on a complex system
- They have never completed a life-cycle and had to live with the consequences of their design trade-offs, or
- They have been kept insulated from the cares of downstream users,
- 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_at_(Sec)ure(Dat)a(.com)Received on Wed Apr 13 2005 - 18:48:03 CEST