Re: Object Databases, only backup for objects in APP?

From: Carl Rosenberger <carl_at_db4o.com>
Date: Tue, 17 Jul 2001 20:43:25 +0200
Message-ID: <9j214d$t8o$05$1_at_news.t-online.com>


Galen Boyer wrote:
> > Object databases take care of references between objects
> > internally. Object databases take care of inheritance
> > hierarchies internally.
>
> I haven't ever worked with object databases, but it seems that
> with an object database, one wouldn't need to design a database
> at all, just design the application and store a specific set of
> objects that are in memory on the java server for safety?

Yes, that is correct.

In addition to the safety issue using an object database also provides funtionality

- to store more objects that fit into RAM on the server
- to use query functionality on all stored objects
- to possibly send a file of objects somewhere
- for transactional ACID changes of data
- to allow changes to classes that contain data


> Is this a clear picture, or does one still design it to enforce
> data integrity, ease of selects, ...?

In an object sense you might call "data integrity" different: "business rules"

Of course you can consider designing critical classes for better query performance.

If you want keys to identify your objects, of course you can add a field to store a key in.

> Is an object database a relational database
> plus support of objects?

Implementations may vary widely. Object database do not need and use a "table" concept, at least none visible to the user. You can only guess, what vendors do behind the interface.

Sure you could provide a relational "table" interface for an object database.
Sure you could create middleware to store objects to tables.

Typically object databasese are completely implemented independantly.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com
Received on Tue Jul 17 2001 - 20:43:25 CEST

Original text of this message