Re: relational vs object

Angus Monro wrote:
> What are the pros & cons between relational & object databases?

Angus,

to get the discussion going, I will supply the cons that I just recently posted to comp.databases.object.

Since we are working hard on our 2.0 release, I am sorry not to have the time for a flame war, that is likely to develop but I will enjoy reading along the "Not true" and "but its ad hocery and against relational theory" replies that some of the candidates here like Lee or Bob may deliver.

Here we go:

(1) Object databases understand objects. You do not need an exchange
layer to convert objects to tables. This greatly reduces the implementation work necessary to build the persistence code in your application. Some research figures talk about 20% to 50% less work during application development. Create your classes and store instances of the objects, thats all you need to do. You do not have to write SQL-Code to interface with the database. The reduced implemetation work also reduces the search for errors and improves the maintainability of your code. There is no risk of forgetting unsafe SQL-strings in your application during refactoring.

(2) Object databases support class inheritance.
Relational databases support this concept very badly: Either you work with one table for the entire class hierarchy or you use one table for every class. The first approach produces monster tables. The second approach needs lots of links during storage and retrieval and makes queries very slow.

(3) Object databases allow you to navigate through your stored object graph.
You can follow links of objects without the need to start further queries. The object database ensures that the graph of your objects is put together in exactly the same way as it was stored. It manages object identities by using object caches and ensures that one unique object will only be instantiated once. With this concept memory usage can be drastically lower in comparison to a relational application where you are served the same data over and over again.

(4) Object databases are faster for many tasks. Ideally the database engine
can be run in-process with your application, without the need for a communication layer.

(5) Object databases do not limit you to fixed length strings or arrays. They
manage your objects as they come.

(6) Object databases come with built-in ID-management. You do not have to
worry about creating and fetching primary keys or foreign keys. Objects are automatically associated with IDs.

(7) Since objects have unique IDs, object databases can do a lot of the
caching work on the client side. This can greatly reduce the load on your server and improve the speed of your application.

(8) Object databases may understand the structure of your classes directly,
by analysing your code. Ideally you have zero maintenance work to manage a "database scheme" (class scheme for object databases).

(9) Object databases may use callback methods to notify your code about certain
database events.

(10) If the object database is written in the same programming language as your
application code, it may be possible to compile the complete application to native code, including the database engine. This may get you the most efficient and small compound application, ideal for embedded use or for use in low ressource environments like mobile phones.

(11) If your application interfaces an object database your application code
can be completely written in one programming language. The programmers do not have to learn an additional databases language like SQL.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com