Re: In an RDBMS, what does "Data" mean?

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Fri, 18 Jun 2004 15:48:43 -0500
Message-ID: <cavkfr$cor$1_at_news.netins.net>


"Laconic2" <laconic2_at_comcast.net> wrote in message news:ltidnQoXXYsQoE7d4p2dnA_at_comcast.com...
>
> "Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
> news:gqffBeBl6x0AFwMQ_at_thewolery.demon.co.uk...
>
> > No. Pick stores metadata in its dictionaries, and has a concept called
> > ASSOCiation.
> >
> > With the pizza, there is no ASSOCiation defined between CHEESE and
> > TOPPING, but with the invoice there is an ASSOCiation between ACCOUNT.NO
> > and AMOUNT. That is, if the programmer has remembered to define it ...
>
> That's a fair enough answer to the question as stated. Data is only self
> describing if somebody made it that way.
>
>
> As far as "if the programmer has remembered to define it" goes, I find
> that no more, and no less, of a pitfall than the REFERENCES constraint in
> SQL.
Only slightly different, for better or worse, in that if the REFERENCES constraint is not there, you can still create a query with the appropriate join, so there is nothing to force you to put in the REFERENCES constraint, where in PICK, the user will complain that they can't get the data out the way they want if the ASSOC is not there, so the dictionary, which is just descriptive, does get that type of accuracy quite soon after deployment if it is not built in from the start.

--dawn Received on Fri Jun 18 2004 - 22:48:43 CEST

Original text of this message