Death to recursion! Re: Child vs parent records

[Ed Kleban]

On 12/11/05 9:36 AM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 12/11/05 5:19 PM, "Ed Kleban" <Ed at Kleban.com> wrote:
> 
>> Why should I not be able to implement a "ChildOf" relationship if I so
>> choose instead of a "ParentOf" relation ship?
> 
> Because usually when people draw hierarchy of objects they put on top the
> parents. 
> 
> I have now wish to draw several pictures which explain this more clean.
> 
> Ed, you CAN make "ChildOf" relation.
> 
>         tableA isChildOf tableB
> 
> No problems. But now rotate it in mind
> 
>                 TableA
> 
>               isChildOf
> 
>                 TableB
> 
> Our parameter kFromParentToChild, will move you DOWN by hierarchy.
> So from top table to down table
> 
> I start to more like names: kDown, kUp  (or other correct english terms)

I don't.  I think you have perfectly good names right now, namely "Left" and
"Right".  They are simple, natural, and inuitive.  You could call them Up
and Down, or A and B, or 1 and 2, or Punch and Judy... it really doesn't
matter as long as you use the same terms in both CreateBinaryLink and
FindLinked.
 
>> If I can use kLeftSide and
>> kRightSide as arguments to FindLinked it makes it perfectly explicit what I
>> want in terms of the relationship that I envision in my own head.  It makes
>> sense and works for 1:1, 1:M, M:1, M:M.  It makes sense and words for TableA
>> = TableB and TableA <> TableB.   It makes sense if I define my relation ship
>> as "ParentOf", "ChildOf", "GivesTo", "TakesFrom", or anything else.
>> 
>> And it does not ever result in the confusion you have, nor make any special
>> fuss about "recursion" that arises when you are faced with trying to figure
>> out how to use, and make sure you have defined your link correctly for
>> kFromParentToChild vs kFromChildToParent.
> 
> 
> 
>