Re: the relational model of data objects *and* program objects
Date: 14 Apr 2005 06:28:20 -0700
Message-ID: <1113485300.619082.282190_at_o13g2000cwo.googlegroups.com>
Kenneth Downs wrote:
> Frank_Hamersley wrote:
> > Chalk my vote alongside Kenneths! When you consider temporal
aspects
> > then "Extended" does indeed become data if the DBMS does not retain
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > temporally appropriate values for the data and the function
(business
> > rule) that can be reliably presented when required by all and
sundry.
>
> I have been seeking a precise way to state this, some kind of bumper
sticker
> phrase that moves derived data from the status of red-headed
stepchild to
> heir to the throne. So far nothing :(
What is derived and what is data depends on the application, doesn't it? In that case, something in the specification needs to state which is "extended" and which is "real data." I fail to grasp the need for and nature of some "transformation" from "extended" to "data."
> The idea is that the extended values are actually more true than
their
> antecedents. A seller and a buyer haggle over the price of widgets,
which
> are 1.00 each. The seller offers 10 widgets at 90 cents each, they
> eventually settle on 15 widgets for 13.00, at which point the
per-widget
> price is of only historical interest.
Again, given that reports can be run against data of purely "historical interest," how is storing this any different than storing "non-historical data"?
> Two points here. The "caching" idea is very strong, perhaps that is
the
> bumper-sticker slogan?
>
> Second: "theory". Why do we allow a body of abstract mathematics to
hold
> the lofty title "theory" when it does not exist to serve human needs?
Of course it does. And what theory are you talking about? To quote Inigo Montoya from "The Princess Bride": "I do not think that word means what you think it means."
- erk