tables and binary links

[Bart Pietercil]

Safari can’t open the page “http://www.valentina-db.com/dokuwiki/ 
doku.php? 
id=paradigma:public:en:documentation:vkernel:vlink:objectptr_advantages” 
  because it could not connect to the server “www.valentina-db.com”.

Not good :-)


On 9-feb-07, at 18:28, Ruslan Zasukhin wrote:

> On 9/2/07 6:53 PM, "Bart Pietercil" <bart.pietercil at gmail.com> wrote:
>
> Hi Bart,
>
>> could somebody please confirm that I understood the use of tables and
>> binary links correctly in this case
>>
>> Schema:
>>
>> Organisations --> cells <----members (personnel)
>
> So cells is MANY to MANY link table, right?
No, in my postgres design this would have been

organisations 1:M cells (= departments of organisations, but more  
flexible, ie projectgroups, special sales teams,....)

Here I understood that I could use a binary link ( organisation 1:M  
cells) ?


cells M:M members (= personnel) so there would have been an extra  
table mm_cellmembers

Here I understood that one could replace the middle table  
(mm_cellmembers) with a binary link  cells M:M members ?


Then back to the cells table
An cell can have a status and a type (ie. status deactivated, type  
projectteam)

This kind of information I normally store in a property table  
( property_name,property_value) .

and have in the cells table a fk_type and fk_status (both pointing to  
the property table (but different rec_ids of course)

The relation would have been Property Table 1:M Cells for fk_type and  
the same for fk_status

Again in my understanding I translated this to binary links

There is clearly something I am missing, why not to use binary link?  
I can say link(recid Property Table with (recid1,recid2,recid3,....) 
Cells) so this looks to me as a valid statement for a binary link.

I think the piece I'm missing is the part on the wiki that is not yet  
complete (advantages of using binary links)

So please tell when to use binary links and when to use object pointer ?

TIA

Bart




>
>> one additional table "listvalues"
>>
>> rec_id,list_id,menuvalue
>
>
>
>> cells in classic db design would have been something like this
>>
>> cell_id (pk)
>> cell_name (varchar)
>> fk_org (fk)
>> cell_type = alistvalue
>> cell_status = another listvalue
>> parent_cell_id --> selfrelation to get a hierarchy structure
>
>
> ---------
>> in valentina using binary links this (I think) would be
>>
>> Table cells
>>
>> cell_name
>>
>> binary links
>> lnk_org:organisation 1:M cells
>> lnk_celltype:listvalues 1:M cells
>> lnk_cellstatus:listvalues 1:M cells
>> lnk_parent:cells 1:M cells
>>
>> So I only have 1 field and 4 binary links
>>
>> Have I understood this correctly (or is it back to the manual?)
>
> I afraid binaryLink will not work here. I need to think on your tables
> little more.
>
> What is 100% clear is
>
> * you can drop PK
> * instead of FK to use ObjectPtr fields
>
>> cell_name (varchar)
>   Org_PTR
>
>   cell_type = alistvalue            <-- what is this?
>   cell_status = another listvalue   <-- also FK to table listvalues?
>
>   parent_cell_PTR --> selfrelation to get a hierarchy
>                        also ObjectPtr
>
>
> -- 
> 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