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

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:40df3048$0$34762$e4fe514c_at_news.xs4all.nl...
> Marshall Spight wrote:
> >>Let's put a new element 'N' into
> >>the list, right after the 'B':
> >>
> >>The new list is [A, B, N, C].
> >>Now what is the set?
> >>
> >>is it UC1: { (1, A), (2, B), (3, C), (2.5, N) } or
> >>is it UC2: { (1, A), (2, B), (4, C), (3, N) } ?
> >
> > It's UC2.
>
> Ok. No argument, just wondering: any particular reason to
> discard UC1?

If you deviate from the integer domain for your index, you no longer have a list; you now have just another set with just another regular attribute. A list or sequence is a mapping from the natural numbers to another set. For example, a string is a mapping from nat -> char.

UC1 is a perfectly valid approach; it's just not a list.

> > The issue here is not performance, ...
>
> Indeed.
>
> > it's interface.
>
> Is it really? Just interface? Maybe I just don't
> understand what you mean by that. I suspect it goes
> beyond interface. To be more specific: I think it is related
> to the information principle:
>
> > The entire information content of a relational database
> > is represented in one and only one way: namely, as
> > attribute values within tuples within relations.
>
> As soon as some order is said to have information content,
> this principle requires that to have it in a relational database,
> this content must be represented as attribute values.

Something the information principal *doesn't* say is that those relations cannot be a subtype of relation. Ordered relation is a subtype of unordered relation, and list is a subtype of ordered relation. And if we allow relationvalued  attributes (RVAs) then that means we also allow lists as attributes.

> So we have to answer the question: which attribute(s')
> values? The answer seems obvious: list typed attributes.
> But that's not the way it is done - so what stops that?
> I know: the lack of the "Spight list algebra"!

Actually, I think it's exactly that. (Not that it needs to have my name on it, of course.) I think we need a *theoretical* understanding of the subtyping relationship between sets, totally ordered sets, partially ordered sets, and lists. (Mathematicians, of course, have had this understanding for years, but not too many people in data management are there yet. Still, I wish I knew as much math as, say Mikito Harakiri.)

We also need the relational language to have a type system that isn't antediluvian. SQL's type system is right in line with other languages of the day, such as FORTRAN, Cobol, and Pascal (or C for that matter.) It hasn't advanced much, at least not in the type system, and it's extraordinary market success has defeated all newcomers.

> > [note if you do them in the wrong order you're screwed.]
>
> No problem. Assume a preprocessor and make a
> macro^H^H^H^H^H shorthand.

Agreed, but I think that for practical purposes you *have* to have this shorthand form.

> > I don't think the choice is intrinsically complex. I think
> > the issue is just that SQL (and TTM for that matter) don't
> > give you even the most basic list manipulation or integrity
> > checks.
>
> The more options we have, the more serious the problem is.
> Is list [A, B, N, C] ambiguous? Is 'insert Y into L1 after B'
> amibiguous?

I'd say "no" and "no." I'm not certain I see your point, though. Maybe it's that the current situation is quite complicated if you want to handle lists? I'd agree with that. That's why I think we need those list primitives (derived from that list algebra) to make it simple.

> Say we have a pizza-attribute 'topping' of type 'list-of-toppings'

Why is that a list? When I go to pizza hut and ask for ham and pineapple, I get the same thing as if I asked for pineapple and ham. Pizza toppings aren't a list; they're a set.

I think part of the reason people see lists everywhere is because they're used to supplying information in the form of a list, even when the order info isn't relevant. This makes for potential program bugs, because

List{ham, pineapple} != List {pineapple, ham} but
Set {ham, pineapple} == List {pineapple, ham}

> Is 'constraint FK topping refers to toppings' ambiguous?

I don't get the question.

> If it is intrinsically simple as you say - what is your
> explanation why SQL (and TTM) do simply not address meaningful
> order?
>
> Maybe we are just overlooking something obvious.

I think Date et. al.'s usual culprit suffices here: lack of education. I would note, ironically, that that group has never managed to clarify the (IHMO) essential distinction between partial order and total order when discussing order.

> > I was more thinking of something like the relational algebra,
> > with its minimal set of operators, additional operators defined
> > in terms of the minimal ones, and a definition of what it means
> > for a set of operators to be complete. Only for lists.
> >
> > Frighteningly, if I can't find something like that, I may have
> > to do it myself.
>
> "Spight list algebra". Sounds good. :-)

I'll get right on it. :-)

Marshall Received on Mon Jun 28 2004 - 00:27:12 CEST