So let's say I've got two Docs: A and R. R is my "referenced" doc, whose UNID is stored in A.
Doc A is commonly opened with a form that dynamically pulls data from R for display to the user.
If I get a conflict with A (e.g. "B") then fine... I'm still pulling from R in either case.
If I get a conflict with R (e.g. "S") then A is still pulling from R. Still no problem.
I find it hard to see how using a key value helps in this case. In fact, it could easily make things worse as now all lookups and references from A are pointing to both R and S, making conflict resolution even more difficult!
Domino is horrible at generating unique-across-replica keys. It's practically the #1 most commonly asked question on these forums. But there's one that works really well at an atomic database level - UNID.
I've got a view with ~80,000 documents, each with its own unique readers field. You haven't even dreamt of slow until you try to do an @DbLookup against that. :-) I've got a dual-CPU Opteron box with RAID 1+0 data, dedicated view indexing drive, 4 gigs of RAM, etc. etc. (read: smokin') that uses up an entire CPU for 4-5 seconds trying to handle one lookup to the thing.
I'll digress here for a moment: It wouldn't be that bad if it wasn't for the fact that by the lookup merely *existing* in an action hotspot kills the server when the form is opened over the web... see PMR 50114,442,000 if you'd like -- I'm about to re-open it since nobody seems to understand my point. You can read more about this serious
Domimo web scalability problem here:
In fact, due to this situation and that PMR I ended up rearchitecting the app and changing the hotspot to use @GetDocField and it resulted in a performance improvement of ~90-100 times faster. Most importantly, though, it helped to reduce the impact of whatever the heck was causing the web scalability problem identified in my PMR.