> With UUIDs there is absolutely no need for that.
Except now (assuming it’s the PK) you’ve added the additional overhead of a UUID PK, which depending on the version and your RDBMS vendor, can be massive. If it’s a non-prime column, I have far fewer issues with them.
> The data is not ephemeral of course.
I may be misunderstanding, but if it isn’t persisted to disk (which generally means a DB), then it should not be seen as durable.
The whole content of the business transaction is persisted as a blob until it's "done" from the business perspective. After that, entities are saved(,updated,deleted) to their respective tables, and the blob is deleted. This gives the users great flexibility during their workflows.
Yes the overhead of UUIDs was something I mentioned already. For us it absolutely makes sense to use them, we don't anticipate to have hundreds of millions of records in our tables.
Except now (assuming it’s the PK) you’ve added the additional overhead of a UUID PK, which depending on the version and your RDBMS vendor, can be massive. If it’s a non-prime column, I have far fewer issues with them.
> The data is not ephemeral of course.
I may be misunderstanding, but if it isn’t persisted to disk (which generally means a DB), then it should not be seen as durable.