BinaryLink vs ObectPtr

[Ruslan Zasukhin]

On 1/24/05 3:28 PM, "Olivier" <vidal_olivier at yahoo.fr> wrote:

> Hi Ruslan and list,
> 
> In my tests to know the advantages of the binary links on objetPtr, I
> made a small bench.
> (in doc, the advantages and Inconvenience of the various ways are not
> explained)
> 
> DB with BinaryLink:
> SELECT * FROM zipcity join street we linkcitystreet where zipcode =
> '75000'
> 
> DB with ObjectPtr:
> SELECT * FROM zipcity, street where street.zipcityptr=zipcity.recid and
> zipcode = '75000'
> ( If I does not put "street.zipcityptr=zipcity.recid", there is a CRASH)
> 
> BinaryLink is faster of approximately 10 %. It is little.
> When Valentina 2 will be optimized, both ways will approximately be so
> fast or binarylink will be even faster?
> Later, to use binaryLink will allow more possibilities?

I have describe this to Lynn, not so far. Let me check my letters.
I will copy here parts of my texts:


-----------------------------------------------------------------------
On 12/30/04 11:49 PM, "Lynn Fredricks" <lfredricks at proactive-intl.com>
wrote:

> Hi Ruslan,
> 
> There is a big section in your notes about Abstraction Links, which mentions
> Foreign Keys, ObjPtr Fields and Binary Links. Are there any other kinds of
> links or keys? Of course, we support a primary key, right?

Yes we support PRIMARY KEY. This is Relational model.

PK + FOREIGN KEY = this is Relational model.
This is the only what have all other RDBMS.


Valentina 1.x also did have ObjectPtr,
Although 1.x did not support PK+FK completely.

Valentina 2.0 support 3 kinds of links.

    FK
    ObjectPtr 
    BinaryLink.

ObjectPtr -- this is analog of DIRECT POINTER from Navigational model,
    although it differ.

FK -- this is pointer by value.

BianryLink -- this is totally new thing. Nobody have it.
    it is best then both above

-----------------------------------------------------------------------

On 12/30/04 11:55 PM, "Lynn Fredricks" <lfredricks at proactive-intl.com>
wrote:

> Hi Ruslan,
> 
> In your doc, you mention that ObjectPtr fields are up to 4 x faster than
> foreign keys. But what are the advantages of using a Binary Link (is there
> anything other than M:M)?

* M : M this is already HUGE advantage!

* I am going write many text on this in docs, because this thing is not
describe in books.

* another main advantage is DESIGN of db structure.

Look, with FK and ObjectPtr to link 2 tables you must insert FK field into
one of them, which play role of pointer to the parent record.

The you have T1 which point T2.
T1 have 3 own fields that describe it info (its real world object).

Now you need add 1 pointer field to establish link.
If around T1 you have 5 tables which must be linked,
then you will have 3 + 5 fields in T1.

Look, 3 fields which keep ESSENTIAL DATA of this table,
And 5 fields which keep LINK information.

LINK information is NOT a property of T1 object,
But Relational model push you insert this info into T1.

This means that IF you change db structure, you will MUST change structure
of already existed tables to add links.

It is obvious that this is bad.
All programming languages try isolate one part of code from other.


BinaryLink (as well as Link abstraction) DO THIS for DBMS world.
You will have in T1 3 fields. Always.
    (of course if you use BinaryLinks only :-)

If you add/remove linked tables, then you just add T3 and new BinaryLink.
T1 is not touched.

-----------------------------------------------------------------------
>>     FK
>>     ObjectPtr 
>>     BinaryLink.
>> 
>> ObjectPtr -- this is analog of DIRECT POINTER from Navigational model,
>>     although it differ.
>> 
>> FK -- this is pointer by value.
>> 
>> BianryLink -- this is totally new thing. Nobody have it.
>>     it is best then both above
> 
> Best for what? Speed? That is what I need to understand -- in marketing 2.0,
> I need to convey why this new type is better.

SPEED also. 

And BinaryLink will use about 2 times less disk space then trick with
    third table to establish M : M link as do RDBMS world.


-----------------------------------------------------------------------
>> The you have T1 which point T2.
>> T1 have 3 own fields that describe it info (its real world object).
>> 
>> Now you need add 1 pointer field to establish link.
>> If around T1 you have 5 tables which must be linked, then you
>> will have 3 + 5 fields in T1.
>> 
>> Look, 3 fields which keep ESSENTIAL DATA of this table, And 5
>> fields which keep LINK information.
> 
> There is where Im getting confused.
> 
> There are three fields of real world data in T1.
> 
> There are five tables which must be linked to T1, so therefore, T1 has 3
> fields (of real data) + 5 link fields (to connect to each of the five other
> tables) = 8 fields.

Correct. And in RDBMS, these 5 fields are FOREIGN KEY fields.

Also note, may happens that 5 tables POINT TO T1,
In this case each of them get this additional FK field,
but T1 have 3 fields. In any case, db have 5 more fields in total.


>> LINK information is NOT a property of T1 object, But
>> Relational model push you insert this info into T1.
> 
> With Binary Links, where is the information stored to make the link, if it
> is not in T1?

It is stored in the NEW SPECIAL structure -- Binary Link.
Internally this is NOT a table. It is quite other format (similar to
indexes).

--------------------------------------
NOTE: in RDBS, developer also can have

    T1 with 3 fields, and T2..T6 tables around it.

    to get better design developer can make links as
    additional tables with 2 fields each:
        T12 -- link T1 and T2
        T13 -- link T1 and T3
        ...

    in case of M : M developer simply MUST to use
    additional table.

NOTE2: 
    in pure Relational model exists ONLY tables.
    even indexes not exists, so strictly speaking
    all RDBMS as MS, mySQL are not pure Relational.


* So we do step forward and add one more abstraction LINK.
* and we have 3 kinds of links.


So as I have told, BinaryLink is not a T12 table.
This is special kind structure. It is smaller and faster.
And the main, it act as abstraction LINK.

>> This means that IF you change db structure, you will MUST
>> change structure of already existed tables to add links.
>> 
>> It is obvious that this is bad.
>> All programming languages try isolate one part of code from other.
>> 
>> 
>> BinaryLink (as well as Link abstraction) DO THIS for DBMS world.
>> You will have in T1 3 fields. Always.
>>     (of course if you use BinaryLinks only :-)
>> 
>> If you add/remove linked tables, then you just add T3 and new
>> BinaryLink. T1 is not touched.
> 
> So is the Binary Link data stored in its own sort of table and contain all
> information related to the linked tables?

Yes. Close to true. Just it is not table.

You can think about Binary link as array of pairs

    { 3, 5 }        rec 3 of T1 is linked to rec 5 of T2.
    { 3, 7 }


> And so if this is true, then no
> linking information needs to be stored in T1, right?

Right.