Re: the relational model of data objects *and* program objects
From: FrankHamersley <FrankHamersleyZat_at_hotmail.com>
Date: Thu, 14 Apr 2005 15:18:50 GMT
Message-ID: <uRv7e.11480$5F3.6845_at_news-server.bigpond.net.au>
>
> 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."
>
> Again, given that reports can be run against data of purely "historical
> interest," how is storing this any different than storing
> "non-historical data"?
>
> Also, if history is important (and it is), why bother storing values
> when you can store the history of the functions/calculations? And
> you'll still need a way of specifying which data should be updated when
> the function changes, versus those which are "first-rate" values that
> are just stored (and thus indistinguishable in my mind from "data" as
> such).
>
> 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."
Date: Thu, 14 Apr 2005 15:18:50 GMT
Message-ID: <uRv7e.11480$5F3.6845_at_news-server.bigpond.net.au>
erk wrote:
> 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."
Not sure what you meant by the last sentence (its late here!).
>>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"?
>
> Also, if history is important (and it is), why bother storing values
> when you can store the history of the functions/calculations? And
> you'll still need a way of specifying which data should be updated when
> the function changes, versus those which are "first-rate" values that
> are just stored (and thus indistinguishable in my mind from "data" as
> such).
Taking Kenneths example - as the widget salespersons manager when I ask for a report on how much discount (from the published price) a particular client has negotiated I need both numbers.
>>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."
Maybe the bumper sticker is "Your best practice is another's failed project". I have no beef with either the theorist or the pragmatist - but only if they do not preach dogmatically that the other is wrong wrong wrong!
Cheers, Frank. Received on Thu Apr 14 2005 - 17:18:50 CEST