Re: Persistence, EJBs and OO-Relational mapping

He wants to know about referential integrity when objects are holding and perhaps modifying pieces of originally relational data outside of the rdbms.

The answer is that referential integrity does not depend on a relational model for the data store. That the relational model (when the data store is handled with sound, relational algebra consistent code) maintains referential integrity is not the reason to choose an rdbms over some other kind of graph structure for the dbms. You can implement referential integrity with any kind of graph structure in your data store. Referential integrity is an application of constraint logic that does not depend on having the data that it applies to stored in any particular data model.

The reason why specifically relational data stores are widely used is good runtime performance compared to the alternatives. It may be simpler to implement referential integrity for a relational model than for a database with an arbitrary graph structure, but that's an internal implementation issue for the dbms vendor, not a user issue. Performance/price and usability are what count for the customer, and *nothing else is any sort of issue at all*.

If your application uses OO-relational mapping, it still must be sound with regard to referential integrity in the context of all of the applications that use that data store. "Persistent objects" in the sense of the current discussion merely complicate the graph of the data store and the constraint logic model for maintaining referential integrity in that data store beyond the complexity that they would have for a purely relational data store as the price of being able to manipulate that data store with objects that may be persisted outside the database proper. The difference between "the database proper" and data persisting in application objects is an arbitrary division of the data store, an abstraction entirely of our own construction. A constraint logic model of referential integrity in the data store must ignore that arbitrary partitioning of the data model into relational and OO parts if it is to be sound with regard to update and exclusion rules that any code using the data store must honor.

Regards,

Clayton Weaver
<mailto:cgweav_at_eskimo.com>

(Seattle)

"Everybody's ignorant, just in different subjects." Will Rogers

-- 

Clayton Weaver


<mailto:cgweav_at_eskimo.com>


(Seattle)