Re: Data Display & Modeling

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c7jflf$3dj$1_at_news.netins.net...
> "mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> news:409d3e6c$0$65124$e4fe514c_at_news.xs4all.nl...
> > What would be an approprate name for this construct?
> > Not "relation", as that would prevent any sensible dicussion.
> > I could not think of one yet.
>
> Yes, it is a relation and, in particular, a function.

I don't see how the above is a function, as relations are N-ary, and (for example) can have multiple candidate keys.

> The model I'm working
> with has names as "descriptive" (and therefore synonyms are prevelent),
> allowing the ordering of the tuple to be what is fixed (and that fits with
> the def of a relation). Typing is also descriptive rather than the
database
> employing types (even sizes) as constraints. This gives the builder
enough
> rope to hang themselves, but also provides some freedom not available to
> developers in SQL-DBMS's.

What value does it provide?

> > The only difference with a relation (or relational variable)
> > would be that it's attributes would be allowed have an exposed
> > internal structure, b-2 (lists) being a relatively simple case
> > of that.
>
> Yes, internal structure and also functions can be defined at any level and
> need not be only set-functions (or type functions). For example, you can
> have navigation functions and record (row-ish) functions.

In relational theory, all types can have functions defined over them. Not sure what's different here. A list's internal structure can be linked list, for example, but its type has operations. The problem with a list is the usual: list of what? A list is a type generator, not a type itself.

> > Say model H allows relations and these constructs.
> > One preliminary thing: I suspect it is practical that
> > we should be able to easily distinguish attributes
> > as either atomic or structured.
>
> We really only need to know what functions can be used on what, right?

What difference does atomic and structured make? In particular, what can one do with a structured type that one can't do with, for example, a string? Or a date?

> > One approach is historical : Why the restriction?
> >
> > Anoter one is: Qualify existing systems as being more H-ish or
> > more R-ish, and let the proponents brag about their qualities.
> >
> > Yet another one is:
> > - what nice thing can't we do with H what we can with R,
> > (or less absolute: what is more difficult), that is: what do we lose?
> > - what we can we still do <duck> what nice properties does this
> > construct inherit from relation </duck>
> > - what nice thing can we do with H what we can't do with R?
> > (or less absolute: what is easier), that is: what do we win?
>
> Here is one nice thing that can be done with H -- a link could be defined
> without requiring a constraint. So, you can link to things outside of a
> centrally managed data source and if you navigate to the link and it is
not
> there (because you can't control it), then you can simply let the user
know
> that it is not there.

I suspect that what you have here is a link type, and a function to resolve that link to whatever's at the other end. That resolution could throw an exception, or return an EmptyResource or such.

However, recognize now that you're in the usual OO value/variable confusion. A link (say a URL) is a value. But resolving can return whatever's currently "at" that target link, meaning it's sort of a variable. And you want to use that sort of structure for all business data? What is such a structure especially good for? I know the Web gives us all visions of sugar-coated systems dancing merrily in lockstep, but I suspect that this is a "data structure" only from a very great distance that views the Web as a database of stuff it doesn't care much about; which is to say, a distance few of us live near.

• erk