Re: POD speed

From: Lee Fesperman (firstsql_at_ix.netcom.com)
Date: 06/14/04 

Date: Mon, 14 Jun 2004 09:01:31 GMT

Chris Smith wrote:
> 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.

It's my experience that people don't investigate enough to determine the disadvantages.
More below...

> 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).

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.

+ Data constraint checking is difficult to code correctly.

+ Even in a single application, constraints may need to be applied in several places in
the program. Incomplete coverage is common.

+ Anyone maintaining must be aware of all constraint requirements.

+ If the database system supports a generic tool for manipulation of data, application
constraints will be ignored.

> 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.)

Good, you agree that RM has a solid mathematical foundation.

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.)

> > 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.

Only if you insist that persistent data and dynamic data have identical considerations
and concerns. I'm not sure that even applies to POD.

> > 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.

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.

> > 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.

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.

> > 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.

OK, a broader category is good. It's a fact of life that enteprise in Java implies J2EE
;^)

> > 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.

I disagree. Truly better tools would dramatically improve the robustness of
applications. Procedural code is error-prone. 

-- 
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS  (http://www.firstsql.com)