Re: Unknown SQL

On Mon, 7 May 2001 15:41:48 -0600, "Jim Melton" <jim.melton_at_lmco.com> wrote:
>At the risk of stirring up the dogs and cats, I would question the validity
>of this statement. One of the criticisms leveled against the object
>databases is that they are too tightly coupled to the application. However,
>the above data model is fraught with application implementation details.
>There is a customer record (in table Customers) that stores a calculated
>balance. This balance is not necessarily up to date with all the financial
>transactions credited to this customer, so the data is not necessarily
>coherent. Sure, the customer record has a last update field, but that is
>purely an implementation detail, not intrinsically part of the data model.

Gadzooks, where to begin woofing?

OK, keeping a computed balance is not relationally kosher in the first place. For precisely the same reasons, it's probably not a good idea in an OO design, either.

"Object database is too tightly coupled to the app." Ah, me. I would say this is true, only if the object design is not informed by relational design principles, as it should be.

Good and bad object and relational designs have a lot in common, or should, but good relational design is far better represented in the literature, as it features a set of fairly mechanical cannonical forms, and most OO literature disclaims such even as a goal.

>OO theory (forget about the database part for a minute) says that you should
>model your data around your domain. This is the most stable part of your
>system because the real world doesn't change nearly as fast as algorithms or
>programming languages or even data storage/retrieval mechanisms.

OO theory says model your data around your domain? I thought building a data model was a relational database thing. Objects may be modelled around a domain -- I mean, better your domain than someone else's, y'know? -- but that's not a data model, that's an object model. Different thing. And again, I propose most fervently, if you want to learn how to model stuff against a domain, you ought to call on relational theory and practice.

>So, a row in the Customers table is analogous to a Customer object. An
>accessor method, get_balance() could return the precomputed, cached (if
>potentially out of date) balance attribute stored with the Customer object
>(just as the relational model above) or it could compute it on the fly by
>accessing the transactions (both credits AND debits) associated with this
>customer. The difference is that the OODBMS will not have to do the join
>(WHERE c.custid = p.custid) because the transactions associated with a
>customer are already associated with the customer, allowing direct access.

Who says the OODBMS will not have to do a join? Maybe I've modelled my domain paying more attention to transactions and for good reason. And anyway, what's the problem with a join? On any decent system it's pretty efficient, and it's hard to see that as much of a bottleneck on any kind of realistic system.

>How is the RDBMS superior there?

Well, the assertion you're responding to, was attempting to show the power and generality of SQL, under the (weak) presumption that an OODBMS would not have a similar capability, or better yet a superset.

This is reasonable to argue here only because various recent posters have proposed that an OODBMS need NOT be a superset of relational, which returns us to the root of this thread, based on an accusatory observation I made a few days ago: proposing that an OODBMS need not support something like SQL, if not a superset, is a terribly uninformed opinion, almost impossible to support by anyone who has actually used SQL in any competent manner. Sure, everyone wants a way to persist objects, and if you don't have any, than any is better than none, but we're talking OODBMS here, not just serialization.

So, RDBMS is superior for all the reasons that make SQL useful in the universe, compared to an object "database" that lacked any such facility. That's your answer, though it doesn't say much of anything controversial.

Joshua Stern
JRStern_at_gte.net Received on Sat Jul 21 2001 - 20:02:28 CEST