multiple XREF

Danielle et jean Thierry-Mieg mieg at kaa.crbm.cnrs-mop.fr
Fri Dec 6 05:26:08 EST 1996


acedb will support arbitrarilly large number of XREF but the performance
degrades, hence the warning:
 Class 109: object rhpanel:Genebridge4 has 1647 > 1000 celLs, please edit the models

you do not have to do anything at this stage but the system is slower and
opening lots of large objects, like in table maker, may use large amounts
of memory

we have the  same problem with the homologies of the nematode sequencing project
and are planning, in a future release, to change the managing of the objects
aiming to speed up the handling of large objects

The one case where you really should change your model is the case where you
have a class using a ?Text like in the following example:

?Foo Bar ?Text

and then i have 50000 foo objects, named foo1 to foo50000
and all of them contain the SAME text value. example

Foo foo1
Bar hello

Foo foo2
Bar hello

Foo foo3
Bar hello

etc. 50000 times

then the text object hello will contain 50000 XREF and this is bad

THis model can be fixed in 2 ways, either declare the model as

?Foo Bar Text

then hello is pure text, is not xrefed, takes no memory, the
drawbaxk is that searching the Foo who contain Hello is no slower

alternativelly, declare hello as a tag

?Foo Bar Hello
         World

the difference with the previious method is that now we have a controlled
vocabulary, Bar can only evaluate to Hello or World

____

In both cases, one can define a subclass

Class HelloFoo
Is_a_subclass_of Foo
Filter "Bar = Hello"  // case Text
Filter  Hello         // case Hello is a tag

this ensures immediate access to all the helloFoo
at no cost

_____

Conclusion

large number of Xref are bad bud not lethal.
it is worth thinking about them and keep them around only
if they are really useful




More information about the Acedb mailing list