Re: Hierachical structures - an overview
Date: 4 Jan 2004 22:11:51 GMT
Message-ID: <Xns9466AEF0BD736FFDBA_at_130.133.1.4>
"Mike MacSween" <mike.macsween.nospam_at_btinternet.com> wrote in news:3ff844d8$0$52882$5a6aecb4_at_news.aaisp.net.uk:
> "Lyle Fairfield" <MissingAddress_at_Invalid.Com> wrote in message
> news:Xns9466425916D4CFFDBA_at_130.133.1.4...
>
>> A Google Search for "Hierarchical Databases" brings up several thousand >> (3860) references. The first twenty are somewhat similar, but scarcely >> definitive in any helpful (to me) way. Generally they are described as >> being like trees, or directory structures, or "Information Management >> Systems" of the past.
>
> Thanks Lyle. Yes, I've done Google searches, and come up with the 3
> approaches I've quoted. That's the reason for this post.
>
>> One points out a common problem: a child with more >> than one parent.
>
> Yes, and I've just established from the client that that isn't a
> requirement. Thank god.
>
>> I think you have been descriptive of your needs in another thread. But >> perhaps, in this one, you could delineate a particular problem or
> situation
>> dealing effectively with which requires specific design consideration.
>
> Sure. But I'll briefly re-iterate for the benefit of anyone who hasn't
> seen those threads. It's an orchestral management system. The area of
> the schema that I think needs to be hierachical is the Tour-Concerts
> section. Like this:
>
> World Tour has
> Regional sections has
> Country tours has
> State tours has
> City concerts has
> Rehearsal, afternoon concert, evening concert.
>
> But the hierachy could range from that (5-10 levels would do it, I
> think) to a simple string quartet playing at a wedding - 1 level.
>
> People (musicians) can be booked in at any level. An arranger (writes
> music) for the whole tour, but doesn't need to turn up at anything else.
> Players need to be booked in at the lowest level, the concert. And any
> level in between.
>
> Potential problem: Let's say I use an adjacency list as a structure.
> When the client calls me, she says - 'Can I book you for Carousel next
> year Mike, not sure of the dates but its 19-26 of October'. I say OK.
> All she has so far is a single event, lasting a week. So once I'm booked
> on it I'm a record in a junction table between the Events table and the
> Musicians table. Then she finds out the dates. She enters them, as
> 'sub-events' of the week long event. Children of the parent. No doubt I
> have some event handler that says 'you are entering dates for this show,
> do you want everyone so far booked onto the show to be booked onto each
> event' or some such. She clicks yes. There are now 2 entries (probably
> 8, one for the week, one for each night) in that junction table. At a
> relational level it looks OK. But at a 'logical' level I'm entered twice
> for the same 'thing'. There should be no need for me to be entered for
> both the parent and the child. If I'm entered for the child it's obvious
> I'm entered for the parent too. Update query needed? Probably. At which
> point the difficulty of querying up the tree using standard SQL in an
> adjacency list might be a problem. There's more. What if she deletes
> every single sub event when she realises she's got it wrong. She'll have
> to re-enter the musos onto the parent event. But maybe rare enough not
> to worry about.
>
> Cheers, Mike
I would be inclined to reverse the hierachy, I think, starting with events
(at the top), which may be linked to "acts" or descriptors such as "state
tour". Something dynamic like musicians who are members of acts could be
handled by linking the event-act link to musicians, (I've done something a
tiny bit like this with telephone numbers where a person is linked to 6
numbers, and the links are linked to type, such as home, office, table)
while static items such as state tours which are members of country tours
could be mapped directly.
An act could, of course, be a solo.
-- Lyle (for e-mail refer to http://ffdba.com/contacts.htm)Received on Sun Jan 04 2004 - 23:11:51 CET