Child vs parent records

[Ruslan Zasukhin]

On 11/15/05 12:22 AM, "Ed Kleban" <Ed at Kleban.com> wrote:

Hi Ed,

>> Okay, let me try to explain.
>> 
>> We have recursive link. Recursive link can in  fact be written as:
>> 
>>         Table1 --- Link  --- Table1
>> 
>> So it similar to
>> 
>>         Table1 --- Link  --- Table2
>> 
>> Right?
>> 
>> We often write 1 : M link between 2 tables as:
>> 
>>         ParentTable  -- link -- ChildTable
>> 
>> Right?
>> 
>> So if you in brain unroll recursive link as above, you can think that LEFT
>> table is PARENT table, ad RIGHT table is CHILD table.
>> 
>> If take example with "Person" table and link "ParentOf"
>> 
>>         Person  ----- ParentOf ------ Person
>>         ^^^^^^                        ^^^^^
>>         parent                        child
>>  
> 
> Ok, now we're getting somewhere, and somewhere that makes some good
> intuitive sense.
> 
> Based on the above, would the following statements be true?
> 
> S1)  Creating a non-unique ObjectPtr field that contains recID values
> referring to records in the same table that contains the ObjectPtr field
> inherently defines a one to many relationship between a record indexed by a
> specific recID value, and all of the records that contain that recID value
> in their ObjectPtr field.

YES. The same correct for 2 different tables.
 
> S2)  If the ObjectPtr field referring to recId values in the same table that
> contains the field is also defined as having unique values, then the
> relationship established is inherently one to one.

YES. The same correct for 2 different tables.
 
> S3)  A one to many relationship can also be referred to as a "parent/child"
> relationship in which any one record associated with a given recID value is
> called the parent of all child records that contain that recID value in
> their ObjectPtr field.

YES
 
> If these are true, then these are the "missing" implicit information that
> experienced database users may take for granted, but which novices (or picky
> readers like myself) would appreciate seeing explicitly stated in the
> documentation.

AGREE
 
> This is still insufficient however, to explicitly explain what values of
> inRecursionDirection actually do.  Let me attempt to define those as well:

Yes, I think it needs add some pictures also
 
> S4) When calling aLink.FindLinked( inRecID, inTableA, inTableB,
> inRecursionDirection )  with inTableA = inTableB, then a value of
> inRecursionDirect = kFromParentToChild returns a VArraySet with the recID of
> zero, one, or many children records having inRecID as the value of their
> ObjectPtr field; whereas
 
> S5) inRecursionDirect = kFromChildToParent returns a VArraySet with at most
> a single parent record identified by the non-zero value in the ObjectPtr
> field value of the child record indexed by recID.  If the ObjectPtr field
> contains zero then the returned VArraySet is empty.

Right.

Only not complete yet:

* you talk only about ObjectPtr always.

* Valentina 2 have also link - FOREIGN KEY.
    it is similar to ObjectPtr by nature. It is a field.

* Valentina 2 also have new link -- BbinaryLink. This is not a field at all.

Methods of Vlink class work for ALL link kinds. So it needs write text in
general form.


-- 
Best regards,

Ruslan Zasukhin
VP Engineering and New Technology
Paradigma Software, Inc

Valentina - Joining Worlds of Information
http://www.paradigmasoft.com

[I feel the need: the need for speed]