How much of "unique" the string that is the current epoch in milliseconds converted to base 36 ?
I know it is not universal. But require such a bad luck to have collision no ?
I am gonna use it for "transaction" primary key. (Every time a user pay, it it a new trasantion).
Uuid are very long, i need to put this pk in qr-code later
Thoughts ?

Hash the milliseconds?

If you combine this with a counter and/or a random element, it should be sufficient. But the timestamp alone could lead to a lot of collision.

Depends on your transaction rate.

Just use a guid and eliminate all your risk :)

@SortOfTested do u know any guid that is short in lengh ? Uuid are vers long

@c3r38r170 yes convert millisecond timestamp to base 36. Creates such a small string

@devapsarl
Does human readability actually matter? I would argue it generally does not.

@SortOfTested i told my self id be rich before the first collision.
And if it came very soon, ill have lot of chance to win the lotery haha. So ill be rich both ways 😂

@devapsarl
Then you really don't care about the cost of a single guid :)

Objectively though, if you do care, just have a database assign the unique key bigint or numeric(20) as identity and take a modest transaction speed hit.

random UUIDs for the win😅

@mojo2012 it is very long, 36 chars ! !
Base 36 of millisecond epoch is 8 char long !

@SortOfTested the problem with counters is that it have a "guessable next value".
But i think i will need to " dare" anyway...

@devapsarl
That's gonna be concurrency hell for you. Let us know how it goes 👍🏻

I'm always going to levy the modern argument of storage is cheap now.

Go the safe route and take a whole GUID. Even though I know it isn't what you want. Don't risk the collisions. Instead imagine the cost of having to solve a collision if you did take the risk.

@devapsarl Oh no, and disk space is getting so expensive!

🤦‍♀️

I finally took a autiincrement counter starting from 1000, convert it to base 36 (that gives lets say UV) and use it as the "user pk", and added a dash and the base 36 of the current timestamp in seconds. Wich make the transaction PK (done by the same user).
Technically no collision unless the same user make 2 transactions in the same second !

That created a short unique sexy primary key.
So happy :)

@Benedikt well did that !

Most people are talking about UUID v4...

Lil difference in spelling, major difference in meaning.

You can store in a QRCode at least 35 chars - remove the hyphens, it fits.

Dead simple.

What you did is technically correct, but very dangerous imho, as u created a very short fixed length string.

Chance that the string will be duplicated is very high....

When looking at long term storage.

Looking at long term usage... I don't think it ends well :)

@IntrusionCM how can collision ever happen when timestamp is a continuous increasing function. And the probability that the same user do 2 transaction in the same second is null.

@devapsarl i said "technically" correct.

I've learned to be very pessimistic.

A user shouldn't be able to create two transactions in a second.

But what if there is a bug? Time shift due to NTP synchronisation? DST change? Malicious user?

Baaad shit happens. It's a law.

You've defined a PK with the constraint that there never ever will be two transactions at the same time, I just pessimistically doubt that this is true.

@IntrusionCM in fact it is the backend that creates the transaction once the payment is confirmed by creditcard aquirer. Thus, it should be created once. If there is a bug, the fact that it is a primary key it wont be stored, and an error would be thrown, and ill be happy to read that stack trace.

I know, i learned the same as u "be pessimistic" ... But here i am on a personnal project where i also must handle the "marketing side". The transaction id will append on a short url and generate a QR-code. The more it is long the bad it is. Every character counts.
Short qr codes are easily read even with high error correction (i need to add a logo so i need the highest error correction)
In all ways, if a problem occur, the transaction will fail, user will try again. No big deal.

@devapsarl and there you have found yourself the best answer.

:)

Don't solve a problem that does not exist.

Good job

@IntrusionCM thx for keeping the debate alive helping me reaching this point.
Greatful

Cheers

Not sure what you are trying to achieve. If users should not be able to guess the next number, so that they cannot steal a code from another person, then seeding with the current epoch milli is almost the worst possible idea.

If I know the aproximate minute when my victim executed a transaction then I only need to check 60000 combinations.

If you need to use a random token with less than secure number of bits (for storing in a human brain or in a qr code) then make the tokens random, but enforce short lifetime.