Re: the relational model of data objects *and* program objects
Date: Thu, 14 Apr 2005 06:56:50 GMT
Message-ID: <Suo7e.10583$5F3.3869_at_news-server.bigpond.net.au>
"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote
> erk wrote:
> > Kenneth Downs wrote:
> >> erk wrote:
> >> > "Extended" isn't data.
> >>
> We see strong value in converting derived values into stored values. This
> is what led me to a systematic way to define derived values, and
ultimately
> this path led to very large code eliminations.
> <big snip>
> >> 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".
> >
> > You misinterpret what I said. Derived values are available at will,
> > assuming of course you have a function definition. "At will" just meant
> > the data needn't be stored and maintained.
>
> I will stick to the assertion that we cannot admit use of the term "at
will"
> for anything but stored values. Or at least, when stored values are
> considered, they claim the term to such an extent that no other solution
is
> in the running. Consider:
>
> First, assume the existence of a format that we have agreed upon for
> specifying formulas.
>
> That being said, the moment that the user supplies data is the best time
to
> store as well the derived information. This allows their retrieval in a
> way that is really and truly "at will", inasmuch as the SELECT command can
> be exected at will.
>
> All other solutions depart from this maximum efficiency. The problem is
> shifting definitions over time. When formulas change over time, you have
> to jump through some serious hoops to preserve the ability to reproduce
> historical information. If you use views then you have to have multiple
> views based on dates, which gets ugly fast. If you use sprocs they become
> loaded with cases and conditionals. While one might argue that this is
all
> computer-generated and therfore not a problem, they are still more
> complicated then simply retrieving a column from a table.
>
> On the other hand, if you materialize the values, they are protected
against
> shifting definitions.
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.
Furthermore the practical considerations of "caching" the results of complex business rules so a simpler select type of operation can be performed, whilst presenting a minor challenge to architects, far outweighs the cost of slavish adherance to theory.
Cheers, Frank. Received on Thu Apr 14 2005 - 08:56:50 CEST