I have looked into open source DBMS in quite some detail. Thought a
description of what I've found so far may be interesting to you. So here
it comes:
I found the same RDBMS like Horst: PostgreSQL and InterBase. I was
leaning heavily towards the latter since it seems more mature (and since
PostgreSQL didn't have foreign keys implemented when I looked at it--it has
fixed this quite recently).
I have increasing doubts that a Relational DBMS is a good choice due to:
* the conceptual gap between OO design and RDBMS
* since my design makes heavy use of object hierarchies, where relations
become almost more important than objects--and RDBMS don't seem to be good
at handling that (eg. recursive ancester queries).
I looked in some detail at object-relational mappings. One of the more
relevant articles here seems to be "The Design of a Robust Persistence
Layer for Relational Databases", An AmbySoft Inc. White Paper by Scott W.
Ambler (http://www.ambysoft.com/persistenceLayer.html). [There are other
interesting papers at http://www.ambysoft.com/onlineWritings.html]. This
approach is also being implemented by some open source folks in java (can't
remember project name off hand). Enterprise Java Bean container managed
persistance seems to take very similar approaches (I followed some
discussion of this on the EJBoss list). And the same goes for tools such
as DODS (Data Object Design Studio) of Enhydra (www.enhydra.org). One of
my main concerns with this approach is performance: to get from object to
physical storage, the path usually leads through persistance manager (w/
cache etc.), JDBC, SQL, internal rep. A lot of overhead and marshalling!
It seemed to me that it was generally accepted that this approach is way to
slow for storing lots of small objects (it works for few large ones).
So I looked into object-oriented DBMS. Found very little in the open
source domain. Some (like OBST) don't seem to be maintained seriously,
others with interesting features (eg. FramerD) seem to be unusable in the
real world (DBMS-level locking, etc.). There are some promising looking
java object stores (eg. ozone), but these seem to be DOG SLOW (according to
a discussion on their mailing list)!!!!
This leaves two very interesting object (or object-relational) DBMS:
* ZopeDB (www.zope.org)
* Mnesia (www.erlang.org)
I've looked a little less into ZopeDB (and am probably unaware of the most
recent developements) and more into Mnesia (basically since I've gotten
real excited about it since I've found it). The following is my impression
so far (I'll be glad for corrections and additions):
Both dbms are best used with the language in which they are implemented,
ie. Python in the case of ZopeDB and Erlang in the case of Mnesia,
respectively. Both these languages provide means of bridging to other
languages (Python has Corba orbs, etc; Erlang has a Corba orb, an ODBC
interface, a Python- (alpha or beta), a Java-interface, and [I believe] a
generic foreign language mechanism).
The strong (and problably unique) points of ZopeDB seem to be:
* versioning support
* support for acquisition (child objects "inherit" attributes from parent
objects)
My doubts on ZopeDB include:
* scalability/distribution (I'm not aware that this is possible)
* high-availability features (redundancy, fail-over, etc.)
Mnesia is a fault-tolerant, non-stop, transparently distributed,
multi-user, object-relational DBMS developed by Ericsson for
telecommunications applications. It has been successfully used for some
years now in ATM telephone switches. It is (still) little known outside
the telecommunications industry. Due to its origins, it has the following
features: (see for more detail)
* multi-platform (can be mixed in a distributed application)
* Fast realtime key/value lookup
* Complicated non realtime queries (with optimizing query compiler)
* Distributed data in support of distributed applications
* configurable degree of fault tolerance (by means of replication)
* non-stop, dynamic reconfiguration (both code upgrades and schema changes)
* complex objects
* concurrent, distributed transactions
* fragmented tables (distributed over several computing nodes)
* incremental, decentralized and selective backups
* module that enables access to Mnesia from other languages than Erlang
(Mnesia Session)
* RDBMS implemented on top of Mnesia available as user contribution (don't
know about how far SQL support is implemented)
* VERY MATURE (tested in ATM switches in harsh non-stop environments for
years!)
* great documentation including training material
* active and very helpful mailing list
* optional commercial support
Erlang is a concurrent, functional language that seems to excell in terms
of time to market (at least as good as Python, see, for example
http://www.erlang.org/ml-archive/erlang-questions/200004/msg00012.html.
This was confirmed in personal discussion with the chief designer of
Ericsson's AXD 301 product).
This compares very favourably to user requirements such as the following by
Jim Self:
> Features such as these, which can provide rapid recovery from catastrophic
> failure and other capabilities, are NOT simply convenient to large 24x7
> operations, they are *absolutely critical*.
(configurable degree of fault-tolerance, etc.)
> Stability must be combined with scalability, efficiency/responsiveness in
> handling bread-and-butter record oriented data operations, and openness to
> ongoing incremental design/enhancement/correction.
(dynamic code upgrades of app and dbms in Erlang).
Looking forward to your comments, corrections, extensions.
cheers
--bud
/------------------------------------------------------------------------\
| Bud P. Bruegger, Ph.D. | mailto:[EMAIL PROTECTED] |
| Sistema | http://www.sistema.it |
| Information Systems | voice general: +39-0564-418667 |
| Via U. Bassi, 54 | voice direct: +39-0564-418667 (internal 41)|
| 58100 Grosseto | fax: +39-0564-426104 |
| Italy | P.Iva: 01116600535 |
\------------------------------------------------------------------------/
