tables and binary links -- future improvements

Bart Pietercil bart.pietercil at gmail.com
Fri Feb 9 15:30:49 CST 2007


Do I understand it correctly that if I was to use binary links in all  
(1:1,1:M,M:M) linking situations I would trade in speed for design  
flexibility?

If this is true, I would suppose that it is would be to calculate the  
loss of speed. Did I understand correct that the not optimized code  
doubles the weight?
So the use of a binary link in NOT(M:M) situation still costs twice  
the weight of 1 Object Pointer. (and would be twice as slow as using  
the Object Pointer)

The advantage is my tables are from the start "uninfected" by (fk)  
key information

Is this the only tradeoff? Or is the use of binary in not(M:M)  
situations really flawed, is there more to it then a design  
optimization?
To put it otherwise if design flexibility matters more to me (in the  
first months) than speed would you still suggest that I would use   
Object Pointers?


TIA

Bart Pietercil


On 9-feb-07, at 21:08, Ruslan Zasukhin wrote:

> On 9/2/07 9:29 PM, "Bart Pietercil" <bart.pietercil at gmail.com> wrote:
>
>> So are you saying that when you have had the chance to optimize the
>> code, the binary link will be preferable ?
>
> So again, yes.
>
> In my vision BinaryLink itself must be very smart and be kind of  
> mutable
> object.
>
> * if we have 1 : 1 Binary link it must store data on disk in one way
>
> * if we have 1 : M link, then it must store data the same to  
> ObjectPtr but
> without "infecting" Many table.
>
> * if we have M : M - then do it as know.
>     and even here possible optimizations if add more knowledge about
>     link, in particular, may happens that in application always
>     queries go from T1 to T2. Then its possible to reduce size of  
> BinaryLink
>     in 2 times, and speedup in 2 times insert/delete
>
> * another dream resolve task of how to use BinaryLink instead of
>     MM link-table which have additional fields. In worse case
>     BinaryLink can hide behind classic MM table with N fields.
>     but will looks more consistent :-)
>
>
> -- 
> 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]
>
>
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina



More information about the Valentina mailing list