Re: repeating groups

dawn wrote:
> Marshall Spight wrote:
> > >
> > > Your logical predicates and related propositions can then look very
> > > much like the language they are modeling.
> >
> > This is a non-goal for me.
>
> I know. The intersection of our interests seems to be the interface
> between user of a database and the database management software.

Yes. There's substantial overlap, but there's also parts that don't overlap.

> Metaphors of all kinds are useful for interface design, including
> visual, language, and mathematics. If you try to use understandable
> variable names, you recognize the importance of modeling with language.

Okay, I guess I kinda see what you mean.

I'm not sure, though, if mathematics belongs in the above list. I think when we do software, we are doing actual math, not metaphorical math. I recognize that this isn't what most programmers think they're doing.

> > > E.g. John flipped the coin and got heads, heads, tails, heads.
> > > Mary's majors have been math, philosophy, business, math.
> >
> > Neither of these are well-formed propositions as I understand
> > the term.
>
> Think of the intersection of our interests in that interface. These
> are English propositions.

I see.

> I don't care if you need monadic second
> order logic or need to split these out into multiple propositions under
> the covers.

Okay.

> > Either:
> > John flipped some coins and got heads 3 times, tails 1 time.
> > or
> > John flipped some coins and got [heads, heads, tails, heads].
> >
> > Those are propositions.
>
> Yes, those are logical propositions.
>
> > Either you care about the order or you don't.
>
> At any point in time.

Sure, sure.

> > Can you think of some operation you want to do that couldn't
> > (easily) be satisfied by one of the above? Up to and including
> > "implement bag operations."
>
> I don't need child bags any more than I need child sets. I'm good with
> child lists that I can interpret as having a meaningful order or not.

Okay, cool.

> > Assuming we agree that sometimes we want order and
> > sometimes not, we would also presumably agree we
> > want data structures for both cases. Would you rather
> > have the set {list, bag} or the set {list, set} available
> > to you? I would prefer the latter.
>
> I'm good with functions (such as relations) with no order and not
> nested with child lists. So, I'll choose {list, function} ;-) so,
> yes, (list, set}.

I agree that functions are an important part of the mix.

> <snip>
> > > Because logical nested bags, sets, and lists
> > > are all implemented as lists,
> >
> > Implementation doesn't matter logically;
>
> Sorry, I chose the wrong word for your world. Conceptual bags, sets,
> and lists can all be placed in the logical model as lists.

I think I see what you're saying.

> > > if I want to indicate that the ordering matters, I call it an
> > > ordered list.
> >
> > Sure. One needs lists; we agree on this. The question
> > is whether one needs bags. I claim not.
>
> I claim not too. But I might store a conceptual bag or set in a
> logical model list. Because of that, I tend to refer to lists (which
> might conceptually be sets, bags, or lists) and ordered lists (which
> are conceptually ordered as well as in the logical model as lists).
> You don't have to like this terminology or care why I use a phrase you
> think is redundant (but isn't) and I am not trying to argue that it is
> a good choice of terminology, but I thought an explanation of it might
> be of interest, especially since I know you are ignoring bags. They
> need not be in an implementation, but lists will be used for logical
> bags if the only other choice is a set.

Okay, I better see where you're coming from here.

(I would propose that it would be better to model bags with sets than with lists, though-- side point.)

> > > But you gain some conceptual simplicity for users this way, so it could
> > > be the optimum solution.
> >
> > Well, I've got 20+ years experience using system that support
> > only ordered data as primitive, (Fortran, C, C++, Java, etc.)
> > and I am confident that this solution isn't enough. It is definitely
> > *not* optimum. As I have said before, I want lists *and* I want
> > sets.
>
> Agreed. However, you could use the model that is working quite far and
> wide of having sets (relations, functions) to model entities, allowing
> attribute lists within those. You need not permit attribute sets
> (relational-valued attributes) if you have list-valued attributes. You
> may, but it adds to the complexity perhaps without sufficient benefit.

Yeah, I hear that. I'm not sure you sufficiently appreciate the added complexity that comes from making the system be irregular, though.

> > Lists have a great bang-for-the-buck, but they don't have
> > as much bang as sets do.
>
> The combination is strong.

For sure!

> > > > It works *better* to handle lists as lists and sets as sets.
> > >
> > > I'm not sure about that.
> >
> > I am.
>
> I know.

Heh. Sometimes I feel I'm being very patient with you, and other times I feel you're being very patient with me.

> > Also, I am hard pressed to imagine a convincing argument that
> > says, instead of treating X as X and Y as Y, just treat everything
> > as X and that's best.
>
> Now there's a condemnation of the RM if ever I heard it.

Well, yes, actually, it is. I have not been at all happy trying to capture ordered data in SQL.

A year or two ago I had a web app that let users manage data in a list. The user-specified order was an important part of the logical data model, so I couldn't gloss over that part-- it needed to be a real 0-n kind of list, such as would be modelled with an ArrayList in Java. The SQL when someone moved a list item from point n to point m was hideous.

> But again,
> these things don't land on your plate as one thing or another, they are
> designed. We can constrain the model to only permit attributes in
> relations; to permit relation-valued attributes; or to permit lists in
> place of relations or whatever. I'm saying that if you broaden the RM
> to include list-valued attributes instead of relation-valued
> attributes, you get significant benefits as you have both sets
> (relations) and lists. If you also add in RVAs, there is definitely an
> added benefit, but it might not balance the cost of added complexity.
> I'm not adament about this -- I can roll with both, but the model I see
> used successfully has only lists within relations. I would like to
> start there and move forward.

Yeah, that's certainly one approach. It's more conservative than what I'm doing. It's less ambitious. It's probably also more likely to succeed techincally, since it's lower risk.

> > Consider: we
> > can also use sets to model lists. We can, in fact, use sets to
> > model everything. How happy are you with that approach?
>
> Hey, I hear you. I agree that you get more features by having sets
> (including relations & functions), bags, and lists. I can tell you
> that the logical data modeling for products that have nested lists
> within relations (functions as they have a designated primary key) hits
> a sweet spot that I haven't found in other products. You might be able
> to hit a sweeter one by pouring more into it, but you might not.

That is exactly the risk.

> > It seems a less difficult choice than
> > deciding between, say, and int and a long.
>
> I don't have a good sense of what changes to the MV data model would
> take it off that sweet spot. That's my hesitation.

Well that's certainly a fair concern.

> > > > Also, the user is not the only entity in play here.
> > >
> > > But maybe the one that has been ignored for too long
> >
> > I see no evidence that they have ever been ignorned.
> > And if they had, what would it matter? What matters
> > is getting the right answer to this question.
>
> You question is clearly different from my mine then. I've gotta turn
> in and it looks like there is lots more below. Sorry to cut it short.

What? You're responding to my 98 paragraph response to your 113 paragraph post with only a 43 paragraph post?! What's that about?

Marshall Received on Mon Feb 20 2006 - 08:43:19 CET