Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

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

From: Robert Martin <unclebob_at_objectmentor.com>
Date: Tue, 13 Jun 2006 13:22:07 +0200
Message-ID: <2006061313220738165-unclebob@objectmentorcom>


On 2006-06-01 04:09:29 +0200, J M Davitt <jdavitt_at_aeneas.net> said:

> An important clarification is needed here: when relational theory
> advocates talk about data integrity they are talking about constraints
> which are expressed in declarative language. The superiority of
> declarative v. imperative languages has long been decided.

In some circles. The one important circle where it has not been decided is the circle application programming. Prolog failed. ML and the other functional language are faring no better (and are, after all, a mix of declarative and imperative styles). Declarative syntax in the application world has not yet succeeded. And I doubt it is likely to succeed in the near future.

I think the reason is known. Application programming is rich in behavior. And it is difficult to describe behavior declaratively. You need things like "The Cut" (a highly non-declarative feature of prolog that nobody could figure out how to get rid of.)

Note, I am not debating whether declarative is better than imperative or not. IMHO when declarative syntax can be used, it is often very valuable. But it doesn't seem to work for everything.

> In part,
> data dogs slam OO languages because they are, essentially, procedural,
> and building systems using them is extremely difficult.

I agree. OO languages are the worst way of building applications, except for all the others.

> Sure, you can
> settle upon "design patterns" and conventions which help all the parts
> fit together, but complexity abounds and the pile of code is littered
> with artifacts which exist only because of the technology chosen.

This is not a symptom that "the data dogs" can exclude themselves from.  They too have their own little artifacts that are related to technology. We could make the observation that in both cases this is a matter of skill rather than an intrinsic failure of the idea.
>
> Moreover, putting any part of the mechanism which ensures data integrity
> in "the application" limits the currency of data -- and that's not
> something those in the data business want to give up.

The only thing I can conclude from that is that the the application should not take care of the data. I think that's incorrect.

Now, if you mean that the application should not be the sole caretaker, I quite agree. The DBMS should apply constraints as approriate to enforce data integrity.

-- 
Robert C. Martin (Uncle Bob)  | email: unclebob_at_objectmentor.com
Object Mentor Inc.            | blog:  www.butunclebob.com
The Agile Transition Experts  | web:   www.objectmentor.com
800-338-6716                  |
Received on Tue Jun 13 2006 - 06:22:07 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US