Using integer primary keys often creates race conditions when you have multiple database shards, so UUIDs have become the standard. (2 different webservers can create a record in 2 different database sync that then sync with eachother in the background). Using UUIDs for SQLite is less common though as SQLite mostly used for small or local applications but developers are used to UUIDs now and even consider them the standard for primary keys now.
wow, I didn’t know we can have multiple databases for a single app/website. I assumed it wasn’t possible when I learned about k8s and the teacher said there will always be one database while you can replicate your frontend/backend pods
If you are owning every little part of the design in every nuance, sure. But how do you configure this in mysqll, postgres, etc etc. does your favorite framework support this easily.
Using integer primary keys often creates race conditions when you have multiple database shards, so UUIDs have become the standard. (2 different webservers can create a record in 2 different database sync that then sync with eachother in the background). Using UUIDs for SQLite is less common though as SQLite mostly used for small or local applications but developers are used to UUIDs now and even consider them the standard for primary keys now.
wow, I didn’t know we can have multiple databases for a single app/website. I assumed it wasn’t possible when I learned about k8s and the teacher said there will always be one database while you can replicate your frontend/backend pods
Both setups are possible.
Can’t you just reserve X bits of the primary key to store a shard ID?
You would be inventing some style of UUID. Include a timestamp in front, so that it is sortable and you have Snowflake.
If you are owning every little part of the design in every nuance, sure. But how do you configure this in mysqll, postgres, etc etc. does your favorite framework support this easily.