Question

All,

I want to generate server side a user id during registration. This id should be sequential to allow for clustered indexing. It also needs to be unique, obviously.

To what extent can I use uniqid("") for this? I am not building Google, and I assume that the risk of 2 users registering at the same microsecond is close to nill – but I have no practical experience on which to base myself. SQL will reject duplicate id’s, and I can have a loop in my php code that will keep on sending new registration entries in case of collisions / data entry failures, but that’s only a good approach if collisions are rare.

Alternatively, I could add a random postcript with uniqid("",TRUE), but then if 2 users register during the same microsecond, the keys can not be sequential anymore.

What is the best, practical approach to my conundrum? Am I overthinking this?

Thanks,

JDelage

Answer 1

uniqid is nothing more than an interface to microtime (which is why it generates sequential IDs), and as such, it could be predictable and could create a duplicate.

This id should be sequential to allow for clustered indexing. It also needs to be unique, obviously. […] Am I overthinking this?

Most databases, including MySQL, include transaction-safe sequence generators. MySQL’s implementation, AUTO_INCREMENT, is pretty darn primitive, but also effective. An auto-inc primary key would ensure uniqueness and is, more importantly, not weird.

That said, just ensuring that the id column in the table is a primary key is complete defense against duplicate IDs.