Feature: Can it provide native snowflake-id about surrealdb

[tobiemh]

Thanks @Ikki-Dai. We used to use xid for record IDs, and I can't remember why we changed it to the current implementation, but I can look at this again. This is based on the Golang xid library.

To summarise, there are a few reasons that an xid could be an improvement on snowflake ids...

The binary representation of the id is compatible with Mongo 12 bytes Object IDs. The string representation is using base32 hex (w/o padding) for better space efficiency when stored in that form (20 bytes). The hex variant of base32 is used to retain the sortable property of the id.

Xid doesn't use base64 because case sensitivity and the 2 non alphanum chars may be an issue when transported as a string between various systems. Base36 wasn't retained either because 1/ it's not standard 2/ the resulting size is not predictable (not bit aligned) and 3/ it would not remain sortable. To validate a base32 xid, expect a 20 chars long, all lowercase sequence of a to v letters and 0 to 9 numbers ([0-9a-v]{20}).

UUIDs are 16 bytes (128 bits) and 36 chars as string representation. Twitter Snowflake ids are 8 bytes (64 bits) but require machine/data-center configuration and/or central generator servers. xid stands in between with 12 bytes (96 bits) and a more compact URL-safe string representation (20 chars). No configuration or central generator server is required so it can be used directly in server's code.

Specifically this part:

Twitter Snowflake ids are 8 bytes (64 bits) but require machine/data-center configuration and/or central generator servers.

Name	Binary Size	String Size	Features
[UUID]	16 bytes	36 chars	configuration free, not sortable
[shortuuid]	16 bytes	22 chars	configuration free, not sortable
[Snowflake]	8 bytes	up to 20 chars	needs machine/DC configuration, needs central server, sortable
[MongoID]	12 bytes	24 chars	configuration free, sortable
xid	12 bytes	20 chars	configuration free, sortable

Therefore if we decide on this, then xid would be a better choice.

Would this work @Ikki-Dai ? Let me know your thoughts.

[tobiemh]

Hi @Ikki-Dai thanks for this feature request. Just 2 questions:

1. Can I ask why specifically a Snowflake ID?
2. And also, what are the issues that you have with the current record ID?

[Ikki-Dai]

1. Snowflake ID can provide compatibility with other RDBMS, they aways use an increment or sequence as id column.
   And lots of project use long type or other number type as designed.
   Snowflake ID can also be used in a distribute system in the feature.

2. current record id is good. and it is designed for mutlti store models.

[Ikki-Dai]

Thanks @tobiemh, i found the xid lib. it seems a snowflake like implementation. If that were the case, everything is ok now.

[tobiemh]

As of commit bb0b10e this should now be possible! This functionality will be generally available in 1.0.0-beta.9.

CREATE person:ulid() SET name = 'Tobie';