How to link records. Re: Question Backlog for Valentina mailing list.

[Ed Kleban]

On 11/16/05 12:45 AM, "Ed Kleban" <Ed at kleban.com> wrote:

> 
> 
> 
> On 11/15/05 11:55 AM, "Ed Kleban" <Ed at kleban.com> wrote:
> 
>> 
>>> Ok, great. Now I understand. :)
>>> 
>>>> 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.
>>> 
>>> Yes, certainly.  And in a full discussion it should be mentioned as well.
>>> But of course it's the ObjectPtr aspect that offers the great performance
>>> and appeal to me and which I intend to use, so it was on the top of my mind
>>> in trying to understand this.
>>> 
>>>> * 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.
>>>> 
>>> 
>>> Yes. I understand and agree.  First I had to understand what it did.  I
>>> could
>>> write something that would serve all cases now.   I very much like
>>> the concept of the Vlink; making the links be an instantiated abstraction
>>> is very cool.  
>>> --Ed
> 
> Well, I take that back.  I clearly don't understand.  Last night in bed I
> started wondering:
> 
> "I wonder if there's a way to simply use a byte-wide field as you would use
> an ObjectPtr field if it is known in advance that the linked-to table will
> never have more that 255 records? "
> 
> Then I thought, "Hmm. maybe that's what Binary Links can do if you create a
> link between a byte-size field in one table with the virtual RecID field in
> another table."
> 
> But I just now read all the doc in both the Kernel and RB Reference about
> Binary Links and decided I don't have a clue about what they do or how to
> use 'em.
> 
> Specifically:  The constructor VBinaryLink takes as arguments a pair of
> tables, and some referece ("power") , deletion, and storage arguments -- but
> has no field arguments.  So my conjecture that it could relate specific
> fields was clearly wrong, that's not what it does, nor is that what the
> documentation says it does.  In fact as the doc clearly states it doesn't
> require field allocations.
> 
> So I guess I'm stuck.  I don't understand these critters.  I understand how
> to create a binary link with VBinaryLink(...), but I don't know how to use
> the link once I have it.  How do I tell the link, or how does the link know,
> which records in Table A correspond to which records in Table B, or vice
> versa?
> 

Ah, I found it.  It's the LinkRecords and UnlinkRecords commands.

Hmm. I'll have to think about this.  I guess you get a performance advantage
from not having to actually put data into the table in order to create a
link.  Therefore you don't have to visit all the records, but rather just
stuff the relation info into the Binary Link table.   I guess that makes
sense.

And I suppose that if the base tables are on disk, but you only need a
temporary binary link in RAM, you get a big boost as well.

But if both are retained on disk, does this end up taking less storage or
more?  I guess if you're only storing a list of which records have
relations, then you need a Ulong index for both each link to designate one
record in each table, but you don't have to have space allocated in
baseTable records that aren't linked.

Aha!  That's the big speed gain.  When you need to check relations you don't
have to visit every record in one of the tables to see if there's a link,
you only need to scan the list of established links in the binary Vlink.