Since it sounds like pretty much everyone uses UUIDs for links (me too, although I may not have an actual arrow drawn), maybe se can turn this thread in a different direction? Given that random synthetic keys do nothing to avoid duplicate rows - and may actually make duplicate rows more likely - what do people do to avoid duplicates. To be clear what I mean by a duplicate:
1 Keller 123 2 Keller 123 3 Keler 123 Rows 1 and 2 are duplicates, row 3 is not. It might be messy/bad data, it might not - but there's no way for the engine to know that. 1 and 2 are duplicates, despite having unique made up numbers for a key. So, the question is: How do you deal with that problem? Here are some solutions I've used and/or seen: * Cover your ears and say "neyh, neyk, neyh I CAN'T HEAR YOUR!" It's not a great technique, but it is simple and cheap to implement. * Ignore the possibility of duplicate rows unless/until it obviously bites you. Depending on data, this might be good enough. In same cases, it's just not acceptable. (Screwing up 100 log Web lines out of 1,000,000? Meaningless. Screwing up 100 transactions in your accounts? Yeah, not allowed.) * Carefully program your system to detect and prevent duplicate rows: -- at point of entry (client-side/UI, etc.) -- at the engine level (triggers, indexes) * Do after-the-fact audits. Either on demand or on a schedule. That's pretty much the world of techniques I've seen. Any thoughts? ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
