5 ms·

I would never store a UUID as a string for exactly that reason. Either a binary or a native UUID datatype. Any developer IMHO who stores a UUID as a string is s

I would never store a UUID as a string for exactly that reason. Either a binary or a native UUID datatype. Any developer IMHO who stores a UUID as a string is suspect.

jacques_chester 12y ago
Postgres has a UUID type, for example.
dozenal 12y ago
I've always seen UUIDs stored as strings. What's the suspect part? Favoring human readability over optimal machine storage utilization?
- bartonfink 12y ago
  Human readability is a concern of a client and is independent of the storage mechanism. Every modern database stores integers in binary format, for instance, but clients display them as a decimal string of characters as opposed to a binary or hexadecimal representation. Timestamps are similarly stored in binary fashion, but often formatted for human readability in the client.
  - dozenal 12y ago
    UUID is not a universally available primitive type like integer or date.
    - lectrick 12y ago
      Someone hasn't used Postgres. http://www.postgresql.org/docs/9.1/static/datatype-uuid.html http://www.postgresql.org/docs/9.1/static/datatype-uuid.html And anyway, all a UUID is, ultimately, is a big number. It's a simple transcoding to get it into base-10 integer format and back.
  - lmm 12y ago
    If you're using an SQL database you're presumably doing so so that humans can run ad-hoc reports (otherwise there are better datastores). So the UX they get for that is important. And in mysql (yes, not the best choice these days, but a reasonable one when the decision was made), if you store UUIDs as binary (there's no native UUID type) then you do not provide a good UX.
    - lectrick 12y ago
      MySQL itself should not be the main interface; there should be some kind of model layer on top of that which does the translation of things like that, such as (for example) ActiveRecord if you were on a Rails stack. That gets you the best of both worlds. OR you could store the uuid twice, once "natively" and once as a computed column. Searches on the native field would be faster vs. an index on a string column. > you're presumably doing so so that humans can run ad-hoc reports (otherwise there are better datastores) oh dear, someone has drank the NoSQL punch... Storing data relationally is NOT something only suitable for ad-hoc queries by end-users! :O

I would never store a UUID as a string for exactly that reason. Either a binary or a native UUID datatype. Any developer IMHO who stores a UUID as a string is suspect.

jacques_chester 12y ago

Postgres has a UUID type, for example.

dozenal 12y ago

I've always seen UUIDs stored as strings. What's the suspect part? Favoring human readability over optimal machine storage utilization?

bartonfink 12y ago
Human readability is a concern of a client and is independent of the storage mechanism. Every modern database stores integers in binary format, for instance, but clients display them as a decimal string of characters as opposed to a binary or hexadecimal representation. Timestamps are similarly stored in binary fashion, but often formatted for human readability in the client.
- dozenal 12y ago
  UUID is not a universally available primitive type like integer or date.
  - lectrick 12y ago
    Someone hasn't used Postgres. http://www.postgresql.org/docs/9.1/static/datatype-uuid.html http://www.postgresql.org/docs/9.1/static/datatype-uuid.html And anyway, all a UUID is, ultimately, is a big number. It's a simple transcoding to get it into base-10 integer format and back.
- lmm 12y ago
  If you're using an SQL database you're presumably doing so so that humans can run ad-hoc reports (otherwise there are better datastores). So the UX they get for that is important. And in mysql (yes, not the best choice these days, but a reasonable one when the decision was made), if you store UUIDs as binary (there's no native UUID type) then you do not provide a good UX.
  - lectrick 12y ago
    MySQL itself should not be the main interface; there should be some kind of model layer on top of that which does the translation of things like that, such as (for example) ActiveRecord if you were on a Rails stack. That gets you the best of both worlds. OR you could store the uuid twice, once "natively" and once as a computed column. Searches on the native field would be faster vs. an index on a string column. > you're presumably doing so so that humans can run ad-hoc reports (otherwise there are better datastores) oh dear, someone has drank the NoSQL punch... Storing data relationally is NOT something only suitable for ad-hoc queries by end-users! :O