|
On 10/23/19 3:24 PM, Laiszner Tamás
wrote:
That's an absolutely reasonable suggestion. I am still in
the exploration phase so while this solution is not completely
ruled out, I have some concerns about it:
-
Although it does not enforce, but the UUID type kind
of suggests a specific interpretation of the data. Of
course the documentation says you are free to use any
algorithm to generate the values, but there are quite a
few standard UUID types and we are not planning to use any
of them.
-
The serialization format is different than needed by
the application and, while once again this is not a hard
technical barrier, that might cause slight additional
complexity and confusion.
-
The value is logically defined as a 128-bit integer,
that is in itself a compound value split into a few "bit
groups". Extracting these parts can be done by simple (and
supposedly efficient) bitwise operators when stored as
integer, but becomes much more cumbersome with UUID, I
guess.
Hey there,
I am currently exploring the options to
utilize 128-bit numeric primary keys. One of the
options I am looking at is to store them as composites
of two 64-bit integers.
I would highly appreciate any comments
or additional information on this topic.
Best regards,
Tamas
Why not use UUID type?
Putting logic and meaning into primary keys? To what end, I
wonder.
|
