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

In article <9crgsr$4ae$07$1_at_news.t-online.com>, Carl Rosenberger says...
>
>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.

Withdraw here. Your description of subtleties of client-server object manipulation sounds intimidating enough.

>> >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.

I was always amased by the creativity of object people. Say you have a login form with 2 fields, would you necessarily combine them into an object?

Even if I have an address form with dosen fields, would I anyhow benefit from combining them together. Because, as soon as I got those values from the user all I need to do is to put them into insert sql statement.

Now, here come various OR mapping tools telling me how much I would benefit if I have objects in middletier. And on the other side I have a stateless html application so that my objects couldn't even outlive a single request. Here the old OODB cliche about assembling disassembling car boomerangs back: why would I have to put any effort constructing my objects if they would be teared apart at the end of the request?

>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.

I wouldn't care as long as it's a controlled leakage. By increasing amount of data you'll get proportionally increased overhead -- this is never a bottleneck.

>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

In relational insertion is never a bottleneck. In a big enterprise system a list of performance problems looks like this:

1. Joining views, easilly totaling to 20-50 tables.
2. Not using bind variables.
3. Getting data from a view when a single base table would suffice.
4. Not mergeable views.

>> >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.

Again, I would emphasise querying, not data modification. Data update transaction is limited by user input, after all.

>
>> 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.

Well, my position is somewhat odd. It's just a historical accident that sometime in the 70s Xerox Park invented mouse and MVC. Now, everybody thinks that Objects and GUI are synonymous. Around the same time Codd invented relational model and it is universally thought as applied to data storage only.

So, is a network of objects the best GUI framework conceivable? Some people push an idea of "declarative UI", where a programmer doesn't construct View objects programmatically, but describes them somehow. Technically, they go after xml, but anybody with a background slightly more fundamental than text processing would easilly dismiss the buzzword. The approach makes sence, however.

Indeed, given an complex UI appication, why can't I ask to find all the combobox widgets with a country list easily? I shipped this monster application last month and customer wants to update country lists everywhere changing the "All" option to blank entry. Please don't tell me "you have to reuse". No matter now bad my implementation is, the request is so simple and it could be easily formulated in -- guess what -- SQL. Some people like Peter Douglass in comp.object already expressed an idea of having relational engine within programming environment... Received on Sat Jul 21 2001 - 20:01:13 CEST