News for hackers. Stuff that matters.
Re:Exploring PostgreSQL 18's new UUIDv7 support by gigatexal on Friday October 17, 2025 @05:38PM (#45622406)
In a well normalized setup idk maybe not. Uuidv4 for your external ids and then have a mapping table to correspond that to something you’d use internally. Then you can torch an exposed uuid update the mapping table and generate a new one and none of your pointers and foreign keys need to change internally.
Re:Exploring PostgreSQL 18's new UUIDv7 support by crazygringo on Friday October 17, 2025 @06:54PM (#45623085)
The point is, that mapping table incurs the same indexing cost that was trying to be eliminated in the first place. Normalization is irrelevant.
Re:Exploring PostgreSQL 18's new UUIDv7 support by Quekid5 on Saturday October 18, 2025 @12:44AM (#45624964)
I wonder if there is a name for such a mapping table in RDBMS-land...?
Re:Exploring PostgreSQL 18's new UUIDv7 support by gigatexal on Saturday October 18, 2025 @06:18AM (#45626224)
We call them lookup or mapping tables.
Re:Exploring PostgreSQL 18's new UUIDv7 support by Quekid5 on Sunday October 26, 2025 @04:35PM (#45715009)
I was thinking something a bit snappier and bit shorter... maybe an Index? Maybe it could be even maintained automatically by the database...