Re: Recursive join - blind alley?

"Mike Sherrill" <MSherrillnonono_at_compuserve.com> wrote in message news:8crnvvkid5f7cvfdu4m4u04ou8mdma9j1m_at_4ax.com...

Some very pertinent points there Mike. Thanks for prompting me to thing about this more rigourously.

> The fact you speak of these things using different names for them is
> one clue.

Perhaps. The names I used are the sorts of names, descriptive labels, that users might apply to them. Whatever the things are.

> If a world tour were a job, and a leg were a job, and a state tour
> were a job, and a concert were a job, and a dress rehearsal were a
> job, and a show were a job, everything would be a job. That's a
> second clue--it's relatively rare for "everything" to be a "whatever
> you like".

That's very true. There are other things in this database, like musicians and instruments.

> But if everything really is a job in the real world, you either have
> only *one* kind of thingy--a job--or job is a supertype, and tours,
> legs, and so on are its subtypes.

Possibly.

> A third possibility is that "job" might not be anything at all--just a
> shorthand way of talking about things rather than a thing itself.

Possibly.

> You can tell which one of these three apply by ferreting out the
> attributes of a tour, a leg, a rehearsal, and so on. Then reconcile
> the attributes.

OK. What they are then, as it looks at the moment, are groups. Things can be grouped together, and the groups can be grouped. Pretty much like assembly/sub-assembly:

As pretty much every component on my car has packed in this summer lets say the engine goes next. I go to my Ford dealer and ask him for:

1 Crankshaft
4 Con rods
8 big end bearing shells
etc. etc.

After 3 hours he says - 'so you want an engine then?'

This isn't a facile example. The engine has child elements and can be a child. You might argue that the engine has it's own attributes (like capacity) that only come into existence once it is assembled.

But mainly the 'engine' thing is a collection of parts, and a very common way of referring to it. And it can be treated as a discrete component.

My groups are the same. Although the European leg will, at the lowest level be made up of things which we can call 'events' - rehearsals, performances and such, it will still be able to be handled as an entity on it's own. Certain staff will be employed just for that thing (the European leg), but perhaps not for the 'events' that make it up.

There is no way atall to predict how various users will want to divide up the events into groups and super groups, so I will make no attempt to come up with any sort of fixed table structure - Tours, Legs or whatever.

I agree, the fact that an entity type might only have the attributes Name, Parent (joint primary key) may look odd. But believe me, these users think very much about things like 'The Hamburg Week' or whatever. To them the collection of events called The Hamburg Week is just as real as that collection of things which we all accept is called an 'engine'.

> >It's perfectly clear what a job is.
>
> It's not clear to me. A world tour seems to have different attributes
> than a dress rehearsal.

Yes. A dress rehearsal has no sub events. In this model.
>
> >This looks like the sort of thing that could be modelled using
> >some sort of hierachical structure.
>
> That's possible. But there are other structures, and "hierarchical"
> doesn't imply "recursive".

Yes, you're right

> >You seem to have other ideas. Perhaps
> >you could let me know what they are.
>
> Imagine the simplest thing that does something useful. That exercise
> will often steer you toward the essential feature.
>
> "Fred Flintstone asks Barney Rubble
> to perform
> at the Bedrock City Hall
> on 06-Jul-2004 at 7:00 pm."

> Tours, legs, and such seem like convenient ways to aggregate
> performances. But, as convenient as they might be, they don't seem
> essential to me.

Very convenient. Also known as essential.

Let's say I 'fix' for Cameron MacIntosh (big West End producer). What do I have? A list of performances:

Perf1, Theatre Royal Drury Lane, 13/9/2003, 7.30, 10.00, West Side Story Perf2, Leeds Grand Theatre, 13/9/2003, 7.30, 10.00, West Side Story

We can see what there is in common about these things, and also what is different. How will Mr MacInstosh's staff refer to these two shows (and the hundreds of others)? One is part of the West End Production of West Side Story and the other is part of the Touring Production of West Side Story.

> >> >To account for the variability I imagined a recursive join.
> >>
> >> What else did you imagine?
> >
> >What does that mean? I imagined what I said I imagined. A recursive join.
>
> I mean, did you imagine anything besides a recursive join? What else
> did you try? For example, did you model a "tour" or "performance" (or
> "cancelled performance")?

One model might be this:

Production (can't have a parent)
one to many
Groups (recursive?) - a sub type of Production? one to many
Events (can't have children)

Where group and event may well be sub or super types of the same entity.

Mike MacSween Received on Wed Jan 07 2004 - 22:42:03 CET