Re: repeating groups

Marshall Spight wrote:
> dawn wrote:
> > Marshall Spight wrote:
<snip>
> > 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.

We are using mathematics as a metaphor for some aspect of reality. A mathematical model is a metaphor. I agree that when we program we are doing mathematics. We are modeling. We are designing. We are constructing. We are solving business problems. We are communicating.  It isn't exclusively mathematics, but that certainly is a significant aspect of it.

> I recognize that this isn't what most
> programmers think they're doing.

I always thought of programming as writing proofs.

> > > > 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.
>
You are very agreeable.

> > > 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.

Great!

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

You can implement an arbitrary conceptual bag as a logical list, but not as a set because you might need to indicate the same value multiple times -- coin flip as example.

> > > > 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.

While I don't have a full appreciation of it from an implementation standpoint, I do understand from an elegance standpoint. I was drawn to the RM because of its logical elegance. I only appreciated MV based on results and then tried to figure out why this somewhat odd mix of pieces was so useful. What you get with this approach of functions being first-class citizens and nested structures being lists only to two levels deep is that every value within a namespace may be reached by the function

fileName(recordID,attributeNumber,valueNumber,subvalueNumber) If you go beyond that to subsubvalues and down the line, what might you lose in conceptual simplicity and is it worth what you gain?

> > > 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.

I just read mAsterdam's response to this and didn't understand it, so maybe he or you could clue me in. But I appreciate your comment.

> > > 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.

Bingo

> > 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.

And since it already exists!

>
> > > 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.

Wow, so much agreement.

> > > > > 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?

It seemed to work as I see no major points of disagreement on this matter now. The biggest might be that I would still rather start with MV and add in whatever it is you think you must have (provided it doesn't mess things up) while you would like to start with the RM and do similarly. I would rather start with anarchy and add in what additional constraints are helpful instead of starting with locks on all the doors trying to free myself somehow. Cheers! --dawn Received on Tue Feb 21 2006 - 05:54:39 CET