ID vs UUID vs PackedUUID

Concretely, when should I use one type of ID rather than another ?

Between :

UNIQUEID()

UNIQUEID("UUID")

UNIQUEID("PackedUUID")

Solved Solved
0 5 1,904
1 ACCEPTED SOLUTION


@Bulubulu wrote:

UNIQUEID("UUID") for more security


Sure


@Bulubulu wrote:

Could creating an ID with this expression make sense: UNIQUEID()&UNIQUEID() ?


Yes

View solution in original post

5 REPLIES 5

UNIQUEID() (with no argument) generates a sequence of 8 random digits and letters suitable for use as a unique identifier within the app, such as a row key. The generated ID is not strictly unique. Instead, it is sufficiently random as to be effectively unique for all practical uses within the app. The chance of a duplicate ID being generated is virtually zero.

UNIQUEID("UUID") generates a version 4 universally-unique identifier (UUID), a sequence of random digits and letters suitable for use as a unique identifier. While the generated ID is not guaranteed to be unique, it is sufficiently random as to be effectively unique for all purposes.

UNIQUEID("PackedUUID") generates a sequence of 22 random digits, letters, hyphens, and underscores suitable for use as a unique identifier. While the generated ID is not guaranteed to be unique, it is sufficiently random as to be effectively unique for all purposes.

Yes, that's what the AppSheet help says, but it doesn't concretely say when to use one system rather than another. The last sentences of each definition seem to mean the same thing in a different way.

  1. There are no sequential keys in the platform for the time being. Idk if quick sync will allow that in the future, but don't count on that. This leads us to the next point.
  2. Since there is no sequential, we need random keys. These are the ones provided by AppSheet by usign the UNIQUEID() expression:
    1. Since UNIQUEID() is generating an 8 HEX characters key, it has some probability of being duplicated, although quite small.
    2. Since UNIQUEID("UUID") is generating an 32 HEX characters key, it's way less possible to have a duplicated key. This is also a standard in some systems and it's the reason I use it with my Supabase Postgres databases.
    3. Since UNIQUEID("PackedUUID") has less characters than the previous one, is has more probability of being duplicated, although quite small compared to the first option.
      This one was introduced alongside AppSheet Databases so I think it's purpose is defined specifically for that one. Also I don't know if there are other systems that make use of it so I cannot persuade you to start using it or prevent it's usage

Finally, you could create any other expression for keys since the main purpose is to be unique. You could add some text before or after a UNIQUEID() expression, make it uppercase or lowercase, add two UNIQUEID() together, etc... all with expressions like CONCATENATE()

Thank you for the clarification.

Should I conclude that all my IDs should be UNIQUEID("UUID") for more security if I plan to make an app with lots of rows?

Could creating an ID with this expression make sense: UNIQUEID()&UNIQUEID() ?


@Bulubulu wrote:

UNIQUEID("UUID") for more security


Sure


@Bulubulu wrote:

Could creating an ID with this expression make sense: UNIQUEID()&UNIQUEID() ?


Yes