You are irritating. You make intemperate remarks, assert gross generalizations and now
you're jumping around, causing confusion. You've attached this to a proper sub-thread I
have going with Green (acrimonious though it may be.) You and I have another sub-thread
going on exactly the same topic. I'd already posted a solid response on that sub-thread
that brings things back on topic and tries to respond to your assertions. Thus, my
flippant response here. I realize that you and Green are tag-teaming.

Until (and if) you respond to that on topic response, I'll satisfy myself with
examining your motivations, because this is very familiar territory for me (google my
usenet discussions with Carl Rosenberger or James/Neo, for examples.)

You are an OO (Object Orientation) zealot. You see OO as the great panacea, a solution
to all software problems. Don't get me wrong; I absolutely love it for what it is --- a
software development technique.

However, I take a much longer and broader view of things. To me, OO is great simply
because it is better than previous main-stream development techniques. It is only a
small step, though.

OO is just an ad-hoc collection of techniques used by good programmers since the 60's
... I know because I was there ;^) It has no theoretical foundation. Even OO experts
will disagree whether a given, simple object design is correct.

The relational model, OTOH, has a very solid theoretical foundation based on
mathematics. It has been the subject of extensive research for over 30 years. An
integral part of the relational model is Normalization. Normalization is a complete
technique for database structure design. Though there is some ambiguity at the extreme
edges, a database expert can easily determine if a design is correct.

Data structure design in OO has no real theory. The simple question of "which class
should a given field be placed in" has no solid answer in OO. The general advice is "put
it where it belongs." The only guidelines are related to how the field is to be used by
the application. However, this immediately falls apart when functionality is added or
changed.

Normalization basically ignores how data is used and works instead with the meaning of
data, in modelling the real world. Adding/changing application functionality has no
effect on the correctness and usability of a normalized design.

OO is shallow; RM is deep.

OO concepts are only applicable in one small place in a DBMS (ignoring presentation
issues) --- in modelling domains. Of course, I use OO in implementing DBMSs, but it is
no more than the ink I use in my pen.

Hmm.  This really strikes me as the expression of a personal preference.  
After all, I could just as easily respond that when you check data
constraints in databases, the constraint enforcement is hidden in the
database, and is hard to check without knowledge of the relational
model, and the code is SQL.  Without accepting that SQL is fundamentally
easier to deal with than Java (which I don't), my argument sounds as
convincing as yours - which is to say, not at all.  There's no
fundamental difference in readability between these two:

   if (value > 100) throw new IllegalArgumentException();
versus
   CHECK (value <= 100)

Of course, if you're comfortable with SQL then the latter will be
familiar, and if you're comfortable with the Java language then the
former will be familiar.

Really?  Outside of referential integrity (which is sometimes a problem
for these kinds of products and which I mentioned earlier), what's so
hard?  You make your instance variables private, write a mutator, and
fail the mutator if the data isn't good.  The concept has been taught in
every intro-level class for an OO programming language for the past
decade.  It's no harder to write if statements in Java than to write
check constraints in SQL.

Maybe you should give an example.  I don't see this being true in
practice.  People do practice encapsulation in OO code at least at the
lowest levels, and duplication of something like mutator-level data
validation is quite rare.  Code duplication problems in practice arise
with application logic instead.  Perhaps there are things possible with
SQL data constraints that I'm not imagining, in which case I'd like to
find out.

Well, or they need to just not mess with argument checking in the
mutator methods.  I'd venture someone would be no more likely to remove
that argument checking than they would be to remove arbitrary data
constraints from the SQL database.

Sure, that's true.  If such a tool is used for data entry or
modification, though, then the data is no longer application-private.  I
could imagine using such a tool for testing and still considering the
data app-private, but then I don't care about data integrity, because
I'm just testing.  If I get something wrong, a test may fail, and then
I'll find it and fix it.

It would be hard not to agree.

I can only say that, if we're talking about the same thing, I couldn't
disagree more.  People can be taught to translate real-world data into
relational tables, and if that's what it takes to get good access to
data, then it's certainly a small price to pay.  It is a translation,
though.  I definitely find that object-oriented programming provides a
great way to model real-world concepts.

I have read C.J. Date's 3rd Manifesto, incidentally, and found some very
interesting ideas there, but not a convincing argument that object-
oriented programming is less suited to real-world modeling of data than
the relational model.  Date seems convinced that by proving that OO
models are less rigorous than relational models he has done this job,
when that misses the point entirely.  The point is that data from the
real world *doesn't* conform naturally to a rigorous model.

So name a "concern" that applies to persistent data but not dynamic
data, which would result in a relational model being more appropriate.  
As I understand it, we're excluding performance here; I'd just like to
see a case where the relational model is clearly, of itself, more
appropriate just because data isn't in use at the moment.

That doesn't match my experience.  I write data migration utilities all
the time.  They aren't hard.  They are so easy that for the most part, I
just throw away the code after it's written, because it's as easy to
rewrite it the next time around.

Again that just doesn't match my experience.  If you'd like to explain
why this is useful for application-private data, please go ahead.  I've
had little problem with managing these changes myself.

(To provide context for these last few comments, the application I spend
a lot of time maintaining in my job does use a PostgreSQL database, but
maintains large amounts of data outside the database; This data we have
of recent attempted to move into the database, but then reversed the
changes because PostgreSQL had trouble with storing large amounts of
data (up to 40 MB) in a single field.  Writing the code to move data
from the filesystem into these table fields and vice versa, and
arranging for them to be run during scheduled maintenance, proved to be
fairly trivial and problem-free.)

Is that last sentence meant in general, or is there some context that
I've missed?