Re: In an RDBMS, what does "Data" mean?
Date: Fri, 04 Jun 2004 17:12:25 +0200
Message-ID: <40c09151$0$15375$e4fe514c_at_news.xs4all.nl>
Dawn M. Wolthuis wrote:
> mAsterdam wrote:
>>Dawn M. Wolthuis wrote: >>>mAsterdam wrote: >>>>>mAsterdam wrote: >>>>>>Dawn M. Wolthuis wrote: >>>>>>>It think it is worth noting that is far more difficult to retrieve an >>>>>>>invoice the way it looked originally after chopping it up >>>>>> >>>>>>You chopped it up. Why?
[chop]
>>So you don't need the to share the internal structure. >>Don't do that, then.
>
> My understanding of relational structure is that it is for the logical view
> of the database, not the internal structure. If we opt for something else
> as the logical level, then we are not doing relational theory, we are doing
> something else (such as Nelson-Pick [un]theory). There are folks,
> particular those working with XML who have worked on non-relational theories
> of databases and I'm reading what I can of what Jan Hidders suggested
> earlier. But, again, if your data model (logical level) is not relational,
> then what's the purpose of relational theory? --dawn
Somehow I get the impression that you put all blame for the chopping (and the need to re-assemble) on relational theory, in particular on 1NF. That is too much blame, I think.
Say we have a date. It has structure, no doubt. Actually it has a different structure for different purposes. It has a different structure in different countries. We may only be interested in one or some parts/aspects of it: day-of-the week, century. Now suppose we did not have a system defined type 'date'. What to do? Are the problems really that different in the context of relational theory?
Well, a little. COBOL has a powerful way of defining types: easy grouping, redefinitions, symbolic values (not without complications, http://home.swbell.net/mck9/cobol/style/88.html) for: the picture clause. Unfortunately it also defines the storage structure - this makes it fragile. Received on Fri Jun 04 2004 - 17:12:25 CEST