3 ms·
And then if you want to list other entities to that user you will have to start mapping the external id and foreign relationships every time to external users?
by mewpmewp2 2y ago
And then if you want to list other entities to that user you will have to start mapping the external id and foreign relationships every time to external users?
And also if you are doing exception logging, for ids/primary keys there's higher odds of them being logged out, including your own logs and also external platforms.
It feels like having primary key set up like this just will complicate everything unnecessarily for the future including many edge cases that you don't foresee.
Just have the main ID not have any meaning.
It shouldn't contain information about the date, it shouldn't be auto increment, it should really be just random.
- sgarland 2y agoThe solution I outlined is the one GitLab and PlanetScale both use internally, so it has been tested at scale and works well, for both Postgres (the former) and MySQL (the latter). > It shouldn't contain information about the date, it shouldn't be auto increment, it should really be just random. That’s a great way to tank performance. You want your PK to be k-sortable.
- deleted 2y ago[deleted]
- brigandish 2y ago> And then if you want to list other entities to that user you will have to start mapping the external id and foreign relationships every time to external users? If we're talking about relational database engines, that's what they do, relate things. One join statement is much the same as another.