Re: POD speed

From: Chris Smith (cdsmith_at_twu.net)
Date: 06/11/04 

Date: Fri, 11 Jun 2004 09:13:37 -0600

Lee,

Thanks for a very civil and thoughtful response.

Lee Fesperman wrote:
> Nope? Can I get something more to the point? Do you believe that such
> alternatives (such as, simple object persistence systems) are not
> ad-hoc and error-prone? I know of no theoretical basis for these
> techniques. Can you enlighten me on this issue?

My fault. Again, I seem that have misinterpreted your meaning. I don't
consider use of such a POD product to be without disadvantages. It's in
that sense that I meant I don't think it's "fine". But I do believe
that there are situations where these disadvantages can be justified.
So I do think it's okay to use a POD if other concerns override their
disadvantages.

As for the two adjectives, I am not familiar with the product mentioned
there, so I don't know if it provides referential integrity guarantees.
That would be my primary concern with calling it "error-prone". Outside
of these referential integrity guarantees, pretty much anything that
could be checked in the database could also be checked in application
code. Since I'd never advocate using a product such as that for data
that spans applications, that would be perfectly sufficient. The OO
model would, in this case, provide one place (in the class's mutator
methods) to check the validity of data within an object).

I'm not sure of any definition of "ad hoc" that makes it sensible to
debate whether or not any persistence product is "ad hoc" or not. Just
to ensure that you'll return to dismissing my opinion as unworthy, I
simply don't see the point in this insistence that relational databases
are based on mathematical theory. Yes they are, of course, and that
makes is much more possible to write query optimizers that do a good job
of finding data; but it doesn't implicitly mean that the database is any
more appropriate for representing data from the real world. (I'm not
disputing, by the way, that the relational model is complete, in that
any data can be expressed according to that model. That much can be
proven mathematically.)

> The double representations of data is natural. The application view is
> concerned with the functionality of the individual application.

That's true, but doesn't change the fact that there are two different
representations of data that the application code needs to deal with.
This is really very simple. A POD doesn't require you to think about
your relational model of data (since it doesn't exist), and as far as I
can see there are no functional O/R mappers that don't require it.
Conclusion: when both are applicable, the POD is the simpler solution in
that way.

It doesn't change things to say that there are different tasks at hand.
That may be true, but the POD can do the persistence part without
exposing the additional representation of data to the application. The
O/R mapper takes you a good distance in that direction, but in the end
often requires very non-OO ways of writing those classes or of working
with them.

> Would you see it as reasonable that two applications accessing the
> same database tables might use a differnt object/relational mapping
> -- that is, different objects?

It certainly seems reasonable, and even expected. I'm not entirely
clear on what you mean; I'd expect the majority of differences between
O/R mapping to come from (in approximately this order):

1. Using different relations.
2. Using different fields of relations.
3. The way that relationships between entities are mapped.

You've excluded #1, but the remaining two still apply. If you're
talking about something else, though, then I'd like to hear more. The
only other differences that come to mind would not be part of the O/R
mapper (for example, the classes would likely declare different methods
for doing things to the data once it's present).

[...]

> What you're talking about might be called "design for the future". I
> am talking about designing for the future but not in the sense of
> predicting changes, including hooks and 'extraneous' code, etc.. I
> was referring to designing a normalized database structure,
> with no extraneous tables/columns.

Sure, but I still think the concern is still there. If it's more
complex to use a relational database than a transparent object
persistence layer, then there's still not a very good reason to place
application-private data into a relational database on the suspicion
that it might change to become more useful. A data migration tool from
the POD to the relational database could be written and run in probably
less than a day as part of the future changes.

Of course, this doesn't apply to applications where it's *not* more
complex to use a relational database (such as when there's a requirement
to select certain data based on rather involved criteria; something that
PODs are conventionally not so good at or that often require learning
their own rather complex alternative query APIs). In that case, I'd go
for the relational database from the beginning.

(Regarding that last sentence: by and large, i don't buy the argument
that PODs should be used because they are faster, which Roedy used to
start this thread; in the few I've tested in this way, the advantage is
reversed when the quantity of data or the number of concurrent requests
gets too high. That's not to say I don't think single apps with low
quantities of private data are *important*, but just that I don't think
performance is a major design factor in data access for those
application.)

> RM eases migration to new structures with powerful abstractions like
> views, allowing existing applications to run without change.

Perhaps so, but aren't we talking about data that is application-
private, and that only later changes to become more widely useful? In
that case, change to the original application is nearly certain to go
hand in hand with the change to make the original data more widely
useful.

> Limiting the discussion to enterprise business applications would
> virtually eliminate POD from consideration.

Sorry; forget I said enterprise. I should have had more forethought,
and realized that enterprise has as many meanings as people using the
word, and that in the past decade or so it has changed common meanings
to "very large" or "big enough that you should use my product". What I
really meant was shared, not end-user installed.

> With main-stream languages, programs are complex, fragile and error-
> prone. One of the big reasons is that they are basically procedural
> and use variables.

Really, though, the most important reason that main-stream programs are
complex is that they solve complex problems. From there, "error-prone"
and "fragile" naturally follow. That's not to say that tools can't
help, but just that we should evaluate tools on the basis of knowing
that they will be used in complex software. 

-- 
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
Quantcast