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

> Mikito Harakiri wrote:
> > >- 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?
>
> No, not necessarily but if you have an OO-backend, it would not do you any
> bad. Of course this is not the the typical usecase where object-orientation
> is of advantage.
>

We have been hunting for cases where OO *does* offer an demonstratable advantage. Found any?

>
> > 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.
>
> Fine, but dependending on your data model, an address can be a complex
> model.
> A single person usually has:
> - a home address
> - a work address
> - phone numbers for each of the two
> - a mobile phone
> - a fax number
> - two or more email adresses
> He/she is linked to a company and has a functionality there.
> If contacts are more frequent, there is a history of events for this
> contact.
> Possibly you might like to store all previous events and mails with this
> contact.
> Linking specific contract documents would also be great.

Often I find it best to make an "other contact" field for all the pagers, fax numbers etc., rather than get "slot happy" with jillions of dedicated fields.

One can have a "Contact" table if needed.

>
> Now how many tables would you use and how many insert statements would be
> necessary?
>
> If you just collect one name, one email adress and one phone number, your
> single insert statement is great.
>
> As soon as you start to remodel reality, things are not as straight-forward
> as they look.
> Roles start getting into the game and a contact might be a customer, a
> partner or someone who is interested to work for you. As soon as you start
> creating inheritance hierarchies, relational databases are very uneffective.
>

Inheritance hierarchies are a poor model of the real world in most cases. The biz world changes graph-wise, not tree-wise for the most part. OO fans often use trees out of (bad) habit, not reality analysis. There is no "tree cop" in the biz world that keeps things trees. If you find this mysterious tree-biz-force, then call agent mOOlder.

(That excludes taxonomies maintained by users and not programmers, such as product classifications, accounting classifications, etc.)

>
> > 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?
>
> Looking at the majority of current web applications, you are absolutely
> right.
>
> Reality is much more complex than the datamodels that are typically used.
> The future will bring applications that will reflect that. When design
> decisions get tough for relational models, OO is the solution.

Nope!

Visa verse. OO totally barfs when you need multiple aspect viewpoints. OO tends to hard-wire a single access path or viewpoint into the software architecture. P/R modeling reduces views into relatively simply EQUATIONS instead of physical code arrangment, which is what OO often does.

>
>
> > >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.
>
> Now this is totally dependant on the application. I do know applications
> where insert performance *is* a bottleneck since this is one part of the
> data process where real-time management is absolutely necessary. An
> affiliated company is storing SMS requests as they come, to name an example.

Do you have benchmarks showing OO faster here.

>
>
> > >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.
>
> I just quoted an example of the opposite.
>
>
> > 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.
>
> All of your points point out a great disadvantage of relational systems:
> For performance reasons, real-world-objects are not transformed to a data
> model that represents them, as they really are. Instead a simplification is
> attempted, to optimize performance. This might work very well in the initial
> implementation. Later in the development process it is discovered that
> something very important was left out in the data model. Then troubles are
> terrible. Reengineering typically consumes 5 times the effort of a rewrite
> from scratch.

Bull crap. In OO you often have to do a bunch of refactoring because OO doctrine dictates associating behavior with nouns, while TASK is a more stable aspect usually[1].
In p/r you often just change a few boolean or relational equations to alter effector nouns, while in OO you have to MOVE code around. It is easier and less brain-bending to change small equations that to mOOve code around.

[1] You can make task-objects, but they look embarassingly procedural.

>
>
> > >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.
>
> ???
> Engineering systems store data as machines generate them.
> How do you think the telemetric data in a racing car is stored?
> CERN needs to store megabytes of data in milliseconds.
>

Well, I never claimed that one paradigm fits all. Perhaps OO does better for CERN. However, in regular custom biz apps, I don't see where OO helps.

Go sell to CERN, but leave us normal-worlders alone.

>
> Kind regards,
> Carl
> ---
> Carl Rosenberger
> db4o - database for objects - http://www.db4o.com
>
>

-T-
oop.ismad.com Received on Sun Jul 22 2001 - 09:11:28 CEST