>Let me propose another slant to the address (phone) issue.
>
>The Navy has a massive database of information that is gather thru a variety of applications. As applications come on-line they either add new information or make use of what's there.
>
>So, as an example, housing addresses are used for the housing people (assigning quarters to people coming on-base), by the safety people for tracking asbestos remediation, and by, say, the commissary which tracks customers and their addresses.
>
>The database can't make the decision to delete an address out of the address table when a customer is deleted from the commissary application. Neither can the application.
>
>So, who's in charge in this case?
>
>Add to this that legacies are being merged into the system over time, so there is no real way to "fix" who needs addresses and who doesn't.

There is a way to handle this. Since the address table in this case is related to a lot of different tables, it will be a separate entity from other tables whether we are talking relational data or XML. In a relational database you will have a related entites table relating people to addresses, another relating safety issues to addresses, etc. In a an object oriented database each entity related to the address entity will store pointers to the address table in a contrainer attributes.

So when when you delete a person or remediation site all you have to do is delete the appropriate tuples in the entity which maintians the many to many relationship (essentially mimicing a containter object the only way a relational database can).In the object back end this is done by the nature of the database. In the relation back end you need to "set up" ths process. You don't ever have to delete an address tuple ; you cannot delete an address tuple if anything is pointing to it; you may or may not, depending on your process, be able to establish business rules at any given point for automatically deleteing addresses -- but only with the understanding that these are dynamic business rules, likely to changes. An alterantive is to never delete addresses automatically, but to make all address deleteion manual done only after all relationships between an address and anything else have been deleted -- perhaps with additional restrictions. Another is to never delete an address, or to only delete with archiving ...

Now with this much business analysis done, you can decide what tier the rules belong in. In a relational database, it is possible to put these rules in the database, the application or in business rules. I gather that an argument for supporting the middle (business rule layer) is that if you put these rules in the physical layer, if you switch to a database that does not support relations between entities in the physical layer, then you have to recode the application. I don't agree that this is always going to be the case; this may be an application that is very relational in nature that simply does not work well against an object back end. In general, I think it is always worth considering putting rules in the physical end that are
A) always true and not application specific.
B) fairly simply, and do not require large amounts of complex code.

I think the decision has to be made with great attention to the specifics of the case -- remembering that full database poratability not only between databases, but between types of databases is not always a requirement.