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
