Re: relational vs object

"Carl Rosenberger" <carl_at_db4o.com> wrote in message news:<a4hl7b$e9b$01$1_at_news.t-online.com>...
> 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

So, OODBMS are great for the programmer. I didn't read anything in there about data integrity or ad hoc querying - the two most important things for the end user. Received on Thu Mar 14 2002 - 08:49:48 CET