This point confuses me. If we're thinking about a web server, you'll pass your data to the frontend with a row ID, so that they can refer to and modify that data in another request? How would it work otherwise?
Am I missing something? I can think of some use cases, but this limitation cuts down on the uses I'd have for this massively.
I.e., it should still be possible to create a column with a public identifier by which you can refer to the row, I assume.
- Row IDs can be reused when the row is deleted. So when the frontend sends a message to the backend to modify that data, it might accidentally modify a different row that was created after the original was deleted.
- You may be leaking the total number of rows (this allows detecting when new rows are created etc. which can be problematic).
If you have nothing else to uniquely identify a row, then you can always create a random unique identifier and put a unique constraint on it.