|
| ▲ | skrtskrt 4 minutes ago | parent | next [-] |
| This was hard enough to enforce when it was just people writing code, and once one of those stupid incrementing integer IDs go in a public API or important codepath, it can be a real pain to rip out. |
|
| ▲ | tyre 4 hours ago | parent | prev [-] |
| So you have a second, opaque unique identifier for the frontend to fetch? At that point why not just use a single column (UUID)? |
| |
| ▲ | ndriscoll 4 hours ago | parent | next [-] | | Higher density for indexes you use for joins. Also you can then use UUIDv4 to hide creation times if that's sensitive too. | | | |
| ▲ | crazygringo 2 hours ago | parent | prev [-] | | Yes, this is standard. And the point is performance. The needs of user-facing ID's (short alphanumeric, randomly ordered) tend to be pretty orthogonal to the needs of internal ID's (raw bits, monotonically increasing, maybe timestamp data). |
|
