Teamsite DCT design considerations

I dont claim to be an expert on Teamsite, but i have put much blood sweat and tears into it. The following is my understanding of how teamsite tracks database changes, and what that means for anyone who designs datacapture templates and uses OpenDeploy.

The IWDELTRACKER tables uses the following info to track records: path of the xml, all its primary keys as defined in the dd files, and all its foreign keys. This works really well if you have 1 primary key, which is paired up with many foreign keys, but not so well if you have many primary keys, which are paired up with many(or one) foreign keys. This is the reason why one of my DCTs is flawed. In this DCT you make a resource, and assign it to many areas, so the primary key in that DCT comes from a replicant, and the foreign key comes from the main body. The problem we are facing with resource DCT right now is that if the user maps a resource to many areas, and then they delete some areas from the DCT, the changes are not deployed to the database.

Rules of thumb are:

1. Only create top-down relationships
2. NEVER use a replicant for a UID
3. Always test for relationship deletions.