Re: S.O.D.A. database Query API - call for comments

Mikito Harakiri wrote:
> >No, that is not true.
> >Object databases also use indices to organize data for efficient
 querying.
>
> A checkpoint. If I, say, have a Shape object with overlap() method, what
 index
> would OODBMS build?

Creating indices for methods is technically possible.

The ODBMS market is very heterogeneous and I think there are products that provide indices for methods.

In general there are two types of object databases: - "Active" object databases provide behaviour similar to that of application servers. Objects "live" on the server side. Locally you only deal with proxies to these objects. This kind of database server typically consumes a lot of memory since many objects need to remain active. Indices for methods would fit into this database model. www.ozone-db.org is an example of a representative.

• "Passive" object databases do not need to instantiate objects on the server side. Objects are handled in an abstract way by shifting byte arrays around. Method indices would typically have a very negative impact on performance. The change of one single object could cause an avalanche of instantiation of objects on the server side.

> >Why do you have to convert objects to strings manually to communicate
 with
> >the database? Can't the database do the job for you? What is the string
> >back-and-forth conversion good for?
>
> I'm not following here.

This is what happens:

• User enters data into forms. Since some business logic needs to interact, the data is stored to objects.
• An object relational mapper creates SQL statements, *strings*, from these objects.
• These *string* statements are sent to the server.
• The query parser searches these *strings* and converts them to an abstract storable form. If the query parser is programmed in a modern way (object-oriented) it might very well create objects here.
• This form (objects possibly) is written to tables.

Now why is the *string* intermediate state necessary for storage? Why can't the database understand objects as they come?

JDBC and ODBC overhead adds to the unnecessary performance leak.

As you would expect, a database that is capable of understanding objects directly has an insert performance which is 10 ^ 1 to 10 ^2 better. http://www.db4o.com/db4o/benchmarks.html

> >Why do you need to fetch IDs after inserting records, just to join them
 to
> >other records? Can't the database do the job for you?
>
> You mean:
> 1. insert master PO record
> 2. get generated sequence ID back
> 3. insert items
> ?
> Optimising away #2 here is minor issue, compared to possibility of
 combining
> steps #1 and #3. But can't do in Relational. Note, that alhough OO seems
 to
> store PO in one shot you previously have constracted PO object in memory
 in
> exactly the same steps. So, I wouldn't upset too much here.

I don't agree with you here.
On 2- or 3-tier systems, the generated ID has to be read back over the network. As this needs to happen sequentially, you have a lot of back-and-forth communication, just to store one single object, that is a little bit further down the branches of the class hierarchy.

Object databases do store objects in one shot on one machine.

By the way:
Someone has been talking about the necessity that object databases store pointers *and* IDs. This is not true. Object databases can also use the pointers as IDs, but not many of them do that.

> After all, if we put all relational features into object database,
 wouldn't it
> just be a better database?

Absolutely.
This is what is happening by the way.
Relational databases try to provide capabilities for inheritance hierarchies. Akmal Chaudhri from Informix (now IBM) has recently posted some code in comp.databases.object.

Object databases try to provide query functionality that would be expected in the relational world.
... back on the main theme of this thread...

> It's not necessarily about functionality only. We can retrieve data in
 both
> approaches -- no question about it. It is that some object features, like
> nesting, make quering much more complicated, and relationists think that
 this is
> fatal.

Relationists sometimes hate object-orientation because it does not match their way of modelling data. We are in the 21st century and soon (with C# and VB.Fred) more than half of the world-wide softare-development will take place with object-oriented languages.

> >Are you informed about Ericssons record-breaking approach?
>
> Sorry, I'm ignorant here. You sound alarmingly marketing, though:-)

No, I don't have any contacts to Ericsson, although I wish I would. If you search Google for "NDB Ericsson" you get some results. I am sorry but I have lost the reference to the excellent article about the technology that I have read some time ago.

> BTW, I symphasize your early attempts to scare away spammers from the
newsgroup.

I don't know to to which incident you refer here.

Kind regards,
Carl

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