Replies: 2 comments 1 reply
-
|
The main problem we have is that we support any database, not only SQL ones. I we talk about MongoDB for example, there is no such thing as auto-increment integer. The benefit of UUID is that they are compatible everywhere without any specific configuration. Regarding performance, I must say that I've never experienced any significant drawbacks with UUID. In my opinion, their advantages in terms of simplicity of generation and uniqueness largely surpass this possibility. |
Beta Was this translation helpful? Give feedback.
-
|
If I want change to IntegerIDMixin, what are all the changes to be done. |
Beta Was this translation helpful? Give feedback.
-
|
The discussions encountered with the use of IntegerIDMixin can be referred to for your consideration. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi all
Just a general question about the choice to use UUIDs. It is an ancient DBA discussion, but my gut feeling always tends to go back to Bigints or the likes to defined primary keys. Main reason being page sizes of indexes which can easily fit in caches where pages with UUIDs are a fair bit larger and will give you lots of cache misses when you are using larger tables which will result in slower database performance. Upscaling your page caches is not always an option, in case you are using a managed database system for example.
I understand that UUIDs give the opportunity to have "uniqueness" across distributed systems, but then it should maybe be an extra column in the
userstable, not the primary key itself. I think that FastAPI Users would be able to be used much more widespread if there was no UUID-as-primary-key assumption.Beta Was this translation helpful? Give feedback.
All reactions