Re: Data Display & Modeling

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c7jofv$868$1_at_news.netins.net...
> I thought that now relations were permitted to have relation-valued
> attributes. I'm sure some think they can and some think they can't.

They can, and they make outer join unnecessary (among other benefits).

> > - model H allows relations as well as chunks (this is the only
> > difference between H and R).
>
> The allowable operators, in particular permitting operations on "rows"
would
> be another, right?

I rarely see this addressed, but am pretty sure operators defined over specific relvars ("relation types" or "tuple types") aren't permitted. But I have to admit I don't really know - Paul? I'm almost to that section in Third Manifesto...

> > >>>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.
> >
> > Is it necessary to mix this in as well?
> > It seriously blurs the issue I thought I understood.
>
> Because I am working with actual products and abstracting a model from
that,
> and because I'm not sure why the products I'm addressing have historically
> provided a better bang for the buck for their companies, I'm looking at
all
> angles.

A good idea, but I simply doubt that list-value attributes is the primary reason. I could be wrong. I suspect you have a good development environment, but don't know.

> Decoupling persistence services and database constraint handling is
> one aspect of the whole.

I view the "constraint handling" portion as primary, and the "persistence" as something the engine does. Users and developers should only have to deal with the definitions of the data, not the mechanics.

> Nothing relevant to databases is "orthogonal" to
> the discussion as it is the entirety of the database approach that makes
for
> happy users, happy owners, etc.

True, but at the same time for intellectual tractability it's important to separate, at least conceptually, and to layer.

> Relational theory has some "rules of the game" (which is often an
advantage)
> and they such things as only permitting set operations (as well as value
> operations for each type). If I understand correctly, such row functions
as
> iterators or hypertext-like links from an entire row would be out of scope
> of relational theory and not permitted, right?

I think this would be a very interesting top-level discussion topic on its own.

> > Then, to prevent nasty gotchas:
> > Let's keep the distinction clear.
> > Atoms and compounds.
>
> And that is the same as scalars and non-scalars, right? The difference is
> that compounds come with functions that operate on the variables or values
> of that type to yield its parts where scalars have no such
database-defined
> functions available, right?

Given that relational mandates user-definable types, and that the only special type generator is the relation (and perhaps the tuple), the database-defined types have no special status. So what again is the difference between scalar and non-scalar? I can define a ListString type from which I can pluck elements, which just happen to be stored in comma-separated format in the string. How is that different than a list, if I give it list operators?

Perhaps the difference being discussed is between types and type generators?

> I pretty much work with the scalar type "string" and everything else
> (typing, for example) has to do with how to view/use (whatever possible
> representation is needed) the string. But that's another story for
another
> day. Cheers! --dawn

That's an important discussion, indeed, since strings are about the least useful type we have...

• erk