This is based on a comp.object discussion:

> In article [9oegrf$me7$1@perki.connect.com.au], Amjad Bashir
> [amjad@heart.com.au] wrote:
>
> > I've Two classes, CUSTOMER and ORDER. Relationship is quite clear that
> > "Customer has orders", one-to-many.
>
> It may not be as clear as you think. If the above is true, it implies
> that if you delete a Customer object, their Order objects are deleted
> as well.


As long as you keep the Order info, one should *not* delete
the customer. This is both for reference and in case the
customer comes back.

However, it is often not practical to keep everything in
the production system. Archiving stuff without "busting"
references (links) can be a tricky business in actual systems.
I once spent several weeks working on an archiving-related
algorithm, but never did "perfect" it. There were cyclical
references in there I suspected, but the contract was up
before I had a chance to track them down to see if they
were legit or data-entry typos.

It might be easier for the DBA to specify a cutoff point
between 'live' and 'arhcived' stuff, and let the
RDBMS take care of that instead of programmers. If something
old is referenced, then it simply takes longer for the
DB to retrieve it.

I don't know if such RDMBS technology exists though. The ID
number as a cutoff point is not always sufficient because
old stuff may still be 'open' in some cases, such as for
a complex/large order. IOW, the granularity between 'active'
and 'old' might be too small to easily automate.