Re: S.O.D.A. database Query API - call for comments
Date: Sat, 21 Jul 2001 18:01:17 GMT
Message-ID: <9cspbt$tk9$07$1_at_news.t-online.com>
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.
> 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.
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.
> 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.
> >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.
> >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.
> >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.
Kind regards,
Carl
--- Carl Rosenberger db4o - database for objects - http://www.db4o.comReceived on Sat Jul 21 2001 - 20:01:17 CEST