How big is yours?

zgudmunt at zgudmunt at
Tue Jun 27 07:04:43 EST 2000

  Hey, guys, thanks for last time. I have noticed what Ed mentioned
about looking through each of very many objects in a large database
leading  to poor performance. I am mirroring the GDB-database amplimer
objects over to my local Ace, with each amplimer being represented by an
STS-object, with up to 15 aliases each (talk about redundancy!) as a
Text tag. I had a problem at first when I was looking for markers by
aliases if they were not found by name; looking through each of those
100.000+arkers and check their alias was of course mindboggingly slow.
But when I changed the Alias from Text to a XREF to an Alias-object and
queried the Alias-class instead, all was well and fast. It did however
give my over 600.000 Alias objects and increased my dbase size !:)


In article <395087D3.288CE1E8 at>,
  Ed Griffiths <edgrif at> wrote:
> > What are the largest ace databases that people have worked with (in
> > size Mb (or even Gb), or number of objects) and have people found
> > performance problems with very large databases (obviously this is
> > dependent on the computer hosting and accessing the database).
> >
> > Are there any theoretical limits on the number of objects an ace db
> > hold?
> This is, unfortunately, a "how long is a piece of string" like
question. The
> number of objects you can stuff into an ace database will be dependent
on the
> size of those objects. I'm sure you can appreciate that the size can
be just
> about anything (allowing for various bits of house-keeping information
> every object stored will need). If you mean "can I have a really large
number of
> objects ?", then the answer is yes, you are likely to run out of disk
> before acedb runs out of index space.
> In terms of performance, again its a bit tricky to be specific, there
are two
> pathological extremes:
> 	- if you have very big objects in your database then they will take a
long time
> to load and use up lots of memory.
> 	- if you have lots of tiny objects and want to search through them
all without
> using acedbs indexes, then each object must be loaded and explored and
> this will lead to poor performance.
> Most databases sit in between these two and acedbs indexing allows
many queries
> to be done without the need to load objects and look through them,
thus giving
> very good query performance.
> In terms of how big a database can get, well this is (as far as we
know) only
> dependent on the biggest file size that can be supported by a system.
The file
> position is usually given by a "long" which could mean anything from a
32 to a
> 64 bit signed integer. This implies that EACH of the database
blockN.wrm files
> could be huge. In practice operating systems usually only allow file
> somewhat smaller than the theoretical maximum allowed by the file
position size.
> Its unlikely that this is going to present problems at the moment.
> hope this helps a bit...Ed
> | Ed Griffiths, Informatics
Group,                                             |
> |               The Sanger Centre, Wellcome Trust Genome
Campus,               |
> |               Hinxton, Cambridge CB10 1SA,
UK                                |
> | email: edgrif at      URL:    |
> |   Tel: +44-1223-494780 (switch  +44 1223 834244) Fax: +44 1223
494919        |

Sent via
Before you buy.

More information about the Acedb mailing list