On Thu, 21 May 2015 13:44:15 +0200 Mark Straver <sqlite-users-list at palemoon.org> wrote:
> > Oh and the other feature! of UUIDs is merging databases... if I > > have a database deployed to 15 customers, each with their own ORGID > > I can easily throw them in the same database without worrying about > > fixing up primary keys and all records related to those keys. > > You wouldn't with sequential PKs either, but instead of stuffing 2 > types of data into a single field (which I think is also a bad idea) > you simply have an extra field with ORGID. The PK should always be > unique to the target DB, unrelated to the source DBs, when merging. Exactly. One extra column makes the key unique across (in this example) organizations. Plus it adds information -- the organization ID -- that would otherwise be lost in the hash. We have a whole Internet running on nonrandom addresses, a world wide web running on client-determined nonrandom addresses. Instead of relying on hashes and patching up the inevitable conflicts, the designers TCP/IP and HTTP wisely decided on human-readable, deterministic identifiers. Strange indeed it is to watch those who build atop that infrastructure assert that hashes are necessary and intergers insecure. --jkl
