Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: Sasa <>
Date: Sat, 03 Jun 2006 08:01:11 +0200
Message-ID: <e5r8is$crn$>

Bob Badour wrote:
> Start with entering, manipulating, reporting and deriving data. Add
> security. Concurrency. Correctness. Adaptability. Logical and physical
> independence. Recovery. That should be good enough for a start.

What do you mean by adaptability, logical and physical independence?

>> I could agree, providing that the already mentioned "host of high 
>> level services" includes something dramatic which would force me to 
>> move my domain logic (combined data and behavior) to SQL.

> Is predicate logic a high enough level service for you to consider
> expressing logic in it?

Sure is for some things. However, how do you implement behavior with predicate logic?

Also, could you please provide specific example of the predicate logic features in any RDBMS of your choice?

Do you consider RDBMSes (or any specific) as the best choice when working with predicate logic? Isn't for example Prolog better suited for this?


>> In my statement, I was trying to accentuate the need for loose 
>> coupling between client and DBMS.

> What makes you think the dbms cannot extend into what you call the client?

It can, the question is whether we want it. Would a DBMS programmer really desire to have large number of SQL statements spread around some non SQL code? If SQL statements are all over the client code, it would be more difficult to adjust the client if some changes in database are introduced. Now imagine that you have more than one such client. Doesn't that make it difficult for both DBMS as well as client code developer? Isn't it in the interest of both that connection between the two is loose rather than tight?


>> Given the fact the DBMS can serve more apps (but actually even one can 
>> mean trouble if SQL code is spread around the app code)

> You have done nothing at all to substantiate the parenthetical comment.
> You are asking us to accept it axiomatically, and we have already
> indicated we do not.

Indeed I didn't, I started writing it in my last post, but deleted to avoid making the post long. My argumentation is given in the previous paragraph.

> , and given the

>> fact that one app might want to switch DBMSes

> Why is that a fact? Do you also expect the app might want to switch

Consider that you make app for one specific company. Now consider that you want to integrate the same app at another company, however that compnay requires you to use some other DBMS and their existing database. Due to company policy you are not allowed to use the DBMS or database you originally used.

This doesn't seem as an unlikely scenario to me. If I start working on a banking application, I would most definitely like to keep my options open, so that I can sell the app to any other bank with minimum changes required.

> I think it would be smart

>> to decouple both as much as possible, which to me means no client code 
>> in DBMS, and very localized DBMS specific statements in client code.

> Define client code.
> This 'client code' to which you refer. What does it do that is not
> entering, manipulating, reporting or deriving data? Of that which
> remains, what does not interface with the external world through some
> device or another?

I implement my UI and domain logic in the client code. I can give you the benefit of the doubt, that lot of it amounts to "entering, manipulating, reporting or deriving data", and that OOP is not the optimal choice (that is why I'm participating in this discussion).

Hence I refer to my question below - how do you envision it? Do you develop the entire app starting from UI in DBMS? Each possible application be it the typical business application or 3D first person shooter?

If not, where do you see the line between RDBMS and other languages? How do you envision their cooperation? What other languages/paradigms do you use/recommend and what are their benefits over RDBMS?

> Now

>> I'm interested with what part you DBMS guys (no irony, or offense 
>> meant) disagree and how do you envision it?

> Marshall already explained that we disagree with your axiom that data
> management is merely storage because the axiom is in fact false.
> Everything you derive from that axiom is pointless.

That much was already clear. Marshall's statement was straightforward, but fairly abstract to me. I thank you for taking the trouble and providing more detailed explanation.

In this thread some people have been suggesting approaches such as loose coupling, making client code independent from specific implementation, treating DBMS more like a storage, using mappers to translate from relational to OO world etc. You and many other posters have been attacking these ideas intensively. I'm interested in hearing counter proposal(s).

Sasa Received on Sat Jun 03 2006 - 08:01:11 CEST

Original text of this message