in this video, I want to share why I use UUIDs as a primary case, especially with a Java project and also Postgres database. In terms of project, it actually doesn't matter if it's Java or any other language. It's just like example I will provide will be from Java. In terms of database, Postgres has UUID type.
That's why I'm using I'm referring to Postgres. But actually, you can use this approach also with different language and even with different database. I also listed advantages and disadvantages because I think whatever you choose, you always need to consider ups and downs. Because every approach has advantages or bad sides or downsides.
And as a reference, I will use my own project. I will put all links in description so you can take a look.
So in terms of project, I am using this nest service and in this project I have a type which I call file entity and this type has a primary key, id field, id column and this column is a string in this case. I have another one which is item entity and in this case it is UIID and I have some annotations to automatically set this UIID.
And also do conversions, for example, when I send it to a controller or REST API. And in fact, we can take a look at this API. So when you save an item, it will automatically generate UIAZ for this item. And when we fetch this, it will automatically return this as a string. So I don't need to do anything.
Whereas if I use FileEntity, in this case, I will do some basic conversion. It's still doable. But you have some additional steps and let me show the steps. So in this case, it will be file controller
and yeah, not file controller, but file service. And what I do additionally here, I manually generate this ID. Before we go deep dive into this project, let's take a look to advantages. Why would you consider using UUID? Because most of us. Just stick with the integer as like incremental integer as a primary key.
And actually this is not a bad, right? So in this use cases, whether this is actually in probably it's most of the use cases, it's a good idea to use this. But sometimes using UUID is also beneficial, especially if you want to have universally unique IDs across all tables, or for example, you want to reference from one table, another object, and you don't want to, for example, let's say.
do database linking or database relations. So you can use different approaches here. You can say, I am referring this type with this ID. And since ID is unique, you can easily get to this type. This is, this depends on use cases, obviously. But technically let's say we are using integers.
So integers has limits. Whereas with UUID, you will probably not hit the limit of duplicated UIIGs. And also it's very hard to get duplications with UIIDs. I provided this this snippet from Stack Overflow discussions. You can take a look. But it's very hard to have duplicated UUIDs. In terms of safety, UUID doesn't reveal amount of data, amount of records in the database or those records.