UUIDs in MySQL follow up

First published on
Last week my blog post on UUIDs in MySQL stirred a discussion on Hacker News.

I wrote the post in about half an hour and stupidly enough, I did not think about UUID v1. I knew about v1 (from the Melissa virus case), v4 and v3 & v5 (which I once used to generate deterministic UUIDs). I just didn't link my case to UUID v1 because I've hard-wired UUID with UUIDv4 in my head.

Here are two observations from the discussion on HN.

First: over time, the first characters of UUIDv1 are still uniformly distributed.



The only reason I had the same prefix was because I filled in all values with one UPDATE query when I initialized the column. If on the other hand you use UUID() whenever you create a new row, the first characters will be distributed evenly.

Second: the different UUID versions should be more clearly distinguished in general. The Zen of Python has a line:
"Explicit is better than implicit."
In following this, I think it's better not to expose any UUID() function, but only explicitly offer the typed versions UUIDv1(), UUIDv4() etc. This is already what most libraries do as far as I've seen.

Popular posts from this blog

"Security Is Our Top Priority" is BS

First published on
A couple of years ago I was asked to give a conference talk about software security. Well, actually I wasn't really asked, my company bought a sponsorship package with a speaker slot and I replied to the internal email asking for volunteers  🤣  Anyway, while preparing my talk, I realized a couple of important points about security that have not left my mind since: Security is limitless . You can always spend more effort to make things more secure. The same goes for quality, safety, employee happiness, etc. The needs of security are opposed to the needs of a convenient user experience . Improving one typically hurts the other. Now some organizations say "Security is our #1 priority". Really? You want to make something that has no limits your number one priority? I mean security is a good thing, but this seems a bit too simple? In fact, hollow marketing claims like that can make me a bit angry. In this post I'll help you understand what to make of statements like that...
Read more

The long long tail of AI applications

First published on
Image
Last year multiple companies asked me for advice. " We are evaluating this AI powered product, but do you think it makes sense at all? It seems a bit niche and we think ChatGPT might make this entire thing obsolete soon. " Long tail - credit to Wikipedia My answer so far has always been: "No, bare LLMs are not going to compete with this product." I think that people are failing to understand the distinction between different classes of AI companies. I see it like this: Foundational AI - creating models like GPT-4 (text), Sora (video) etc. Applied AI - using existing models to create smart applications. Note that there are also companies not focusing on AI - they will start lagging behind, let's forget about them ;) There are orders of magnitude  (!)   more companies that will deal with Applied AI than Foundational AI, and they will be very busy for decades to come. Here's why: To get the most out of LLMs, you have to ask the right questions. LLMs have acc...
Read more

The Future of Programming Systems - four thoughts

First published on
Image
Last week I gave a 20 minute mini talk at M&I Partners in Zeist about the Future of Programming Systems, and how the work of architects and engineering teams will grow closer together in the future. I'm completely obsessed by this topic so I'm excited! Here is that talk expressed in a blog post, slightly modified based on some feedback and new thoughts. Ok! Thank you for inviting me and sorry for not keeping to the original format as requested. I proposed this idea instead and it was accepted, so in part Matthijs (the organizer) is to blame and I hope it is OK with all of you as well ;) When cycling here, I realized I needed to make a last minute change and added "Systems" to the title. I believe that limiting ourselves to the activities of the programmer is too narrow, and we should have solutions that involve everyone who is in the lifecycle of software. So it's about the System  and that includes the designers, architects, users, database administrators, o...
Read more