Live data from Hacker News

New UUID Formats

ietf.org

171–172 of 172 posts

Re: New UUID Formats

#171

Earlier quoted context omitted.

Can you give an example of an issue you faced with auto incrementing keys? Though I can imagine scenarios, the worst I've ever run into was maxing out the integer size, bit that was easily remedied.

There are a few, but I'll sumarize; A) data merging. Merging multiple data sets together with auto-Inc is tricky - especially in the case of related tables. B) data distribution /replication - especially on and off phones - especially if phones are creating data records offline, then syncing later. C) parent-child forms. Parent has to be committed to the dB before children can be added. D) data imports - again especi…

Thanks! Those are a great set of examples.

Perhaps one through-line is that if IDs are not created by a single source, don't rely on auto incrementing IDs.

The parent/child one is interesting. When I've worked with hierarchical data, I tend to wrap the whole process in a transaction, so it may be many commits (by depth), but one transaction.

Re: New UUID Formats

#172

Earlier quoted context omitted.

There are a few, but I'll sumarize; A) data merging. Merging multiple data sets together with auto-Inc is tricky - especially in the case of related tables. B) data distribution /replication - especially on and off phones - especially if phones are creating data records offline, then syncing later. C) parent-child forms. Parent has to be committed to the dB before children can be added. D) data imports - again especi…

Thanks! Those are a great set of examples. Perhaps one through-line is that if IDs are not created by a single source, don't rely on auto incrementing IDs. The parent/child one is interesting. When I've worked with hierarchical data, I tend to wrap the whole process in a transaction, so it may be many commits (by depth), but one transaction.

>> if IDs are not created by a single source, don't rely on auto incrementing IDs.

Data design outlives programs, and environments by a long time. Circumstances change.

So when I designed the db, there was a single database. But 30 years later we live in a world with smart phones.

Making design decisions because of _current_ circumstances can bite you hard later on.

Reading parent /child. Yes there are ways to mitigate the issue, but it's extra work and code to do so. Ultimately you need the parent id before you can add the children though.

Post reply on HN