Re: POD speed
From: Chris Smith (cdsmith_at_twu.net)
Date: 06/14/04
- Next message: John: "Re: ResultSet within ResultSet"
- Previous message: James: "ResultSet within ResultSet"
- In reply to: Lee Fesperman: "Re: POD speed"
- Next in thread: Lee Fesperman: "Re: POD speed"
- Reply: Lee Fesperman: "Re: POD speed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 14 Jun 2004 08:41:19 -0600
Lee Fesperman wrote:
> Good, you do agree that the simple object persistence model is not
> appropriate when data spans applications.
>
> Enforcement of database constraints in application code is one solution
> generally recognized as 'error-prone'. Here's some reasons:
>
> + Constraint enforcement is hidden in application code. It is hard to
> check (validate) and requires programming language knowledge. The code
> is procedural.
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.
> + Data constraint checking is difficult to code correctly.
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.
> + Even in a single application, constraints may need to be applied in
> several places in the program. Incomplete coverage is common.
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.
> + Anyone maintaining must be aware of all constraint requirements.
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.
> + If the database system supports a generic tool for manipulation of
> data, application constraints will be ignored.
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.
> Good, you agree that RM has a solid mathematical foundation.
It would be hard not to agree.
> However, the Relational Model is not an academic exercise in math. It
> is explicitly intended for modeling real world entities and
> relationships. Decades of use have shown that is does a very good job
> of it.
>
> OO has been sold for its real world modeling but has not met that
> promise. OO's emphasis is on programming artifacts, not real world
> entities/relationships. See Date's writings on this subject (3rd
> Manifesto or check dbdebunk.com.)
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.
> Only if you insist that persistent data and dynamic data have identical
> considerations and concerns. I'm not sure that even applies to POD.
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.
> I don't see the migration as easy. Simply, a persistent data design
> that ignores database design concepts is going to be harder to get
> back on track.
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.
> Lockstep (hand in hand) changes are much harder; they tend to be all
> or nothing. RM abstractions allow piecemeal changes. This is useful
> even when only one application is involved.
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.)
> I disagree. Truly better tools would dramatically improve the robustness
> of applications. Procedural code is error-prone.
Is that last sentence meant in general, or is there some context that
I've missed?
-- www.designacourse.com The Easiest Way to Train Anyone... Anywhere. Chris Smith - Lead Software Developer/Technical Trainer MindIQ Corporation
- Next message: John: "Re: ResultSet within ResultSet"
- Previous message: James: "ResultSet within ResultSet"
- In reply to: Lee Fesperman: "Re: POD speed"
- Next in thread: Lee Fesperman: "Re: POD speed"
- Reply: Lee Fesperman: "Re: POD speed"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
