BinaryLink vs ObectPtr

Mon Jan 24 15:29:04 CST 2005

OK, thank you VERY much for all this precision!

It is important to know WHERE we go.

I am going to use the binary links in my project.

Good work and still thank you.

olivier

Le 24 janv. 05, à 15:03, Ruslan Zasukhin a écrit :

> 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.
>
>
> _______________________________________________
> Valentina-beta mailing list
> Valentina-beta at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina-beta
>