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

"Mikito Harakiri" <nospam_at_newsranger.com> wrote in message news:6LgI6.12$vg1.77_at_www.newsranger.com...

[snip and now going off topic on the thread. . .]
>
> 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?

Username and password? Sure. On the backend, I have an object that represents this user. It contains the username, password, hints and some other
stuff. This is passive. I also need to keep track of how many times this person
tried to login and cut them off if they go over a certain amount (hacker). I
have to keep history of when they were logged on. This is active. Once they're
logged on, I need to give them a database session, I need to check their permissions,
I need to store their userid into the change logging database, I need to. . .

And if you were just asking if it was worth packaging up two values into a single object for convenience, then sure, I would do that as well. Costs little
and benefits somewhat.

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

So let the Address object handle that. Say I want your address: Should I have
to call a dosen different methods then recontruct it?

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

Hint: Your stateless html application is the problem.

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

There are exceptions to your "never", but I'll grant you the point.

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

That's the same point twice in a row, so its time to mention that applications
do batch transfer as well and that is limited by the insert performance. "Time to create another monthly business billing period. Load up that data warehouse."

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

Excellent point. Would you join me in blaming SQL? "What happened to the functional part of relational theory :-?"

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

If you can "chunk" xml down to handling messages rather than an entire page redraw, I'd agree. There is also some very interesting work done on building guis with constraints/declarations, but this is object-based. Hmm. I'd say GUI
frameworks are where OO has done best; its the other stuff that's hard. IMHO,
there is no argument that OO has triumphed with GUIs, but I would be willing to admit that the rest of the application is up for grabs.

> Indeed, given an complex UI appication, why can't I ask to find all the
 combobox
> widgets with a country list easily?

Because no list widget should know it happens to be displaying "countries". (The application should know, though.) If 2-tier blending of application logic and
gui displays taught us one thing, it was "don't do it". But to continue. . .

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

That's a leap I cannot follow. Care to show how SQL will find all the widgets
that display countries, then update their behavior to change the "all" option
to blank entry? And if you're talking about storing the gui "schema" and "instances" in a relational database, then ok, but that's equivalent to using an
O/R mapper to doing the same thing and having the same capabilities. Are you seriously suggesting we do this, or did I just miss your point? Received on Sat Jul 21 2001 - 22:15:44 CEST