7 ms·
> For example, imagine a client that can generate a UUID and at a later time save that to remote database. DBs can return inserted data to you; Postgres and SQ
by sgarland 2y ago
> For example, imagine a client that can generate a UUID and at a later time save that to remote database.
DBs can return inserted data to you; Postgres and SQLite can return the entire row, and MySQL can return the last generated auto-increment ID.
> Or imagine two separate databases that get merged.
This is sometimes a legitimate need, yes, but it does make me smirk a bit since it goes against the concept of microservices owning their own domain (which I never thought was a great idea for most). However, it’s also quite possible to merge DBs that used integers. Depending on the amount of tables and their relationships (or rather, lack of formally defined ones) it may be challenging, but nothing that can’t be handled.
I mostly just question the desire to dramatically harm DB performance (in the case of UUIDv4) for the sake of undoing future problems more easily.
- paulddraper 2y ago> DBs can return inserted data to you; Postgres and SQLite can return the entire row, and MySQL can return the last generated auto-increment ID. Assuming you can+want to talk to a database right then. The useful part of UUIDs is that they can be generated anywhere, locally, remotely, same DB, separate DB, online, offline, and never change.
- paulddraper 2y agoAn example of the latter is when I worked with healthcare systems. It was not uncommon for systems to merge datasets, either due to literal M&A or to share records and coordinate care. A globally unique ID was important, despite not having a globally centralized system.