ACEDB vs. RDBMS
Danielle et jean Thierry-Mieg
mieg at kaa.crbm.cnrs-mop.fr
Wed Apr 2 03:28:54 EST 1997
Obviously, i have a biased opinion, but i would say that
acedb is to be recommended if the following criteria are met:
1) A very complex schema, that cannot be developped at once, but
will need continuous refinement in parallel with the accumulation
of the data
2) The type of questions that will be asked are rather complex, with
rather fuzy answers, that one tries to refine progressivelly. The
acedb browsing capacities are useful in this case and have no
equivalent in a relational dbms
I would rather recommand sysbase in the following case
1) Simple schema, that can be designed from the start and does
not contain too many n.n relations and does not need recursivity
2) The type of questions that will be asked is: succession of
decorelated simple questions with simple answers
Within this context, i would then list the following goodies of acedb:
1) The ace file format, which is a powerful system to prepare and exchange
data between data curators.
2) The existence of an easy graphic browsing interface
3) The availibility of a biology-layer, if the application is about genetics
4) Portability (any unix machine), mac (with some limitations), windows in development)
and price (ace is a freeware). This implies that you can actually redistribute
the complete system, say on a CD, something impossible with sysbase.
5) Ease of use, i seriously believe that ace is much easier to configurate and use
Finally one should consider the following question: concurency.
Sybase has a well designed transation system, which will allow roll backs and
refined lockings. This is essential for an application like a booking agency,
with many users in simultaneous write access.
Ace is much simpler minded. The graphic acedb creates a global lock allowing
a single user with write access at the time, and the modifs are not echoed
to the other "read access" users in real time.
The non graphic client server system allows parallel downloading of data by
many users, it is intended for example for collection of robots sending their
independant data in parallel. This is now well tested.
A graphic client system is beeing developped and now runs in our hands, but is
not yet released.
Therefore, if you do need real time simultaneous write access with partial locks,
and roll backs, use sybase/oracle
Last issue is speed and quantities of data.
In principle, sybase/oracle is unlimited, whereas acedb needs to keep around
5-10% of the data in ram. But this apparent difference is misleading.
On a 32 Meg machine, you can run ace with around 300.000 objects with
a complex schema at high speed. With say 1M objects, you will need
more memory or the performance would totally degrade because of
swapping. However, this is really a lot of data.
On a similar machine, your sybase oracle will work with that amount or
more data only if you do not perform too many joints. This implies
that you are asking simple questions from a simple schema which was
indeed our first criterion to choose sybase. If you start asking complex
questions and make joins, acedb is actually much more powerful.
During tests ran on a big dec alpha server by Otto Ritter in decembre
1995 on several million biological objects with a complex schema,
acedb was about 10 times faster than sysbase, both to load the data
and to answer queries.
I would therefore conclude that the quantity of data is not a criterion
pushing one way or the other, it is the complexity of the schema that matters.
More information about the Acedb