Nice video. Another advantage of UUIDs over auto increment ids is that you can add related objects in one go. Take for example Ticket and TicketLines : with auto increment ids, you first insert a Ticket, fetch the inserted id and then insert the TicketLines. With UUID you can do it in one batch as the Ticket id is generated client side, saving one roundtrip to the database server.
You can use a CTE for that, and solve parent/child problems, no need for a UUID. The performance of UUIDs is quite bad for many reasons. Also, there is the option of having a natural primary key, and the parent/child issues disappear. For example in a database that is about email activity in the table email is the parent primary key. So I try to insert, do an on conflict do nothing (searching for it will be a performance error), and insert the child records. You truly need to be doing something with pretty intensive inserts or something you have no control of like a system with producers and consumers and the producers are partners).
I really liked your video, it was interesting to learn about the concept of Auto vs. UUID. Really liked the on-the-walk style XD could watch some environment while watching, like taking a actual virtual walk with you =D.
Glad to hear it m8, making these videos is a hobby of mine where I just share some thoughts on things so the casual setting suits me perfectly. Have a great day and thank you so much for watching!
cool , new conpect in mind thank you.. i was reading a post about generation stratrgies and they mention this UUID i was like what the heck are they talking about and you made it claire for me.. cheers
I'm just learning coding now, so far just as a hobby but I'm considering a career as a developer or even a SQL developer. One thing I'm curious about at this stage is merging databases. Isn't this part of data warehousing? I've read that UUID's can greatly slow CRUD operations, but I expect they'd be needed in these situations. So, I'm thinking of using UUID's in some of my coding projects not because I think I would use them in most situations, but just so I can experiment with database merging, migration and maybe small-scale warehousing.
1. They could be necessary if you have a single database but many producers of data, many of them partners and you need the absolute best insert performance and the select and group performance is not that important. I know he knows this but don't want to do a 50-minute video. 2. Having many databases, or a distributed database is a case. But if you are really under control you can add a prefix to the autoincrement. UUIDs trash your indexes and they are 128 bit numbers in a world full of 64-bit computers. So every single comparison requires either the vector union or a little program. 3. So avoid UUIDs as much as possible until you truly master them, but they are a blessing for consumer-producer distributed installations. 4. They are also useful when you have a dynamic system, that breaks the "prefix" solution. or requires an authority to generate the prefixes when the instance is launched. 5. Many of the indexing nightmares of the UUIDs will be solved with the implementation of the next-generation UUID that contains a time component. The indexes are going to perform both in terms of query and maintenance.
Distributed systems are a edge case problem that is not universal to programming. UUIDs are more trouble than they are worth. If you spend all your time worrying about how complicated your program is GOING TO BE you most likely will never reach any level of complexity because you are doing pre-optimizations that affect your current growth..
Nice video. Another advantage of UUIDs over auto increment ids is that you can add related objects in one go. Take for example Ticket and TicketLines : with auto increment ids, you first insert a Ticket, fetch the inserted id and then insert the TicketLines. With UUID you can do it in one batch as the Ticket id is generated client side, saving one roundtrip to the database server.
You can use a CTE for that, and solve parent/child problems, no need for a UUID. The performance of UUIDs is quite bad for many reasons. Also, there is the option of having a natural primary key, and the parent/child issues disappear. For example in a database that is about email activity in the table email is the parent primary key. So I try to insert, do an on conflict do nothing (searching for it will be a performance error), and insert the child records. You truly need to be doing something with pretty intensive inserts or something you have no control of like a system with producers and consumers and the producers are partners).
Thank you , for the AHA moment
thank you. your explanation make me understand why should i use UUID. have a great DAY!!!
I really liked your video, it was interesting to learn about the concept of Auto vs. UUID.
Really liked the on-the-walk style XD could watch some environment while watching, like taking a actual virtual walk with you =D.
Glad to hear it m8, making these videos is a hobby of mine where I just share some thoughts on things so the casual setting suits me perfectly.
Have a great day and thank you so much for watching!
Straight to the point explanation. Thanks a lot!
I do not know how you did it, but I literally just had a "ha-ha" moment. 👍
Glad to know i wasn't the only one debating this in my head... in 2021.
Thanks for your great explanation! ❤
Awesome Bro. So clearly explained . Well understood by me. Many thanks for sharing. 🙏🙏
You are timeless bro.
Nicely explained. Thanks! :)
cool , new conpect in mind thank you.. i was reading a post about generation stratrgies and they mention this UUID i was like what the heck are they talking about and you made it claire for me.. cheers
A good insight on this topic. Btw i noticed something in the video, why so many Volvos out there??
ty, great explanation!
UUID great for programmers but horrible for databases. Will cause page splits in indexes (B+ trees)
I'm just learning coding now, so far just as a hobby but I'm considering a career as a developer or even a SQL developer. One thing I'm curious about at this stage is merging databases. Isn't this part of data warehousing? I've read that UUID's can greatly slow CRUD operations, but I expect they'd be needed in these situations. So, I'm thinking of using UUID's in some of my coding projects not because I think I would use them in most situations, but just so I can experiment with database merging, migration and maybe small-scale warehousing.
UUID definitely impairs the performance of DBs with InnoDB engine, esp. under high load, this is what I'm certain about.
Can you make a new video about this but nano id vs UUID?
I'm using them to generate unique download urls :)
1. They could be necessary if you have a single database but many producers of data, many of them partners and you need the absolute best insert performance and the select and group performance is not that important. I know he knows this but don't want to do a 50-minute video.
2. Having many databases, or a distributed database is a case. But if you are really under control you can add a prefix to the autoincrement. UUIDs trash your indexes and they are 128 bit numbers in a world full of 64-bit computers. So every single comparison requires either the vector union or a little program.
3. So avoid UUIDs as much as possible until you truly master them, but they are a blessing for consumer-producer distributed installations.
4. They are also useful when you have a dynamic system, that breaks the "prefix" solution. or requires an authority to generate the prefixes when the instance is launched.
5. Many of the indexing nightmares of the UUIDs will be solved with the implementation of the next-generation UUID that contains a time component. The indexes are going to perform both in terms of query and maintenance.
Why don't you give an ID to each database using auto-increment?
Aha!
Sadly uuids have fairly large performance hit. Plus they take a ton more space. I guess its just a cost people have to live with..
Walking down the street no none to hang with so lets make a video about programming
aha
A guy crossing streets at red is not a good teacher
Distributed systems are a edge case problem that is not universal to programming. UUIDs are more trouble than they are worth. If you spend all your time worrying about how complicated your program is GOING TO BE you most likely will never reach any level of complexity because you are doing pre-optimizations that affect your current growth..
very cold comment. Anyways, aren't they slow for indexing as well when compared to normal auto increment keys?
@@Cognitoman they are a few disadvantages and even more warm comments.
@@owensoft lol I have no idea why I said "very cold comment"
@@Cognitoman good luck on indexing in distributed databases
Nicely explained. Thanks! :)