4 ms·

> What kind of stupid logger logs a uuid without a clue as to what kind of object it identifies? The code cannot know what kind of object an uuid identifies, i

by seppel 6y ago

> What kind of stupid logger logs a uuid without a clue as to what kind of object it identifies? The code cannot know what kind of object an uuid identifies, it can only assume that it identifies what it expects. So it you might see: "Unknown person 550e8400-e29b-11d4-a716-446655440000" in the log files. Much more helpful for debugging, however, is: "Unknown person order-550e8400-e29b-11d4-a716-446655440000". Then you know somebody accidentally put an order id where a person id belongs. This is an easy example, in the real world you have persons, groups, representatives, accounts, acls, etc, which are easily confused. If you just have an uuid, you will have a hard time figured out what it actually is.

SigmundA 6y ago
This is why you have column headers? If you just want it to look that way in a text log, then sure prepend the type with the id wasting some space there, but to use it throughout your db eats up tons of space from both text encoding the id and repeating the column name in the data over and over.
- StreamBright 6y ago
  >> but to use it throughout your db eats up tons of space I think human resources and outages cost a lot more than disk space these days. If I can trade disk space for either of those I will do it in a blink of an eye.
  - SigmundA 6y ago
    Not just disk space, larger index size mean less fits in caches and memory, more I/O etc. These are keys which are typically used constantly by an app in the db with joins etc. They are some of the hottest data typically and you want to avoid cache misses on them if possible.
- seppel 6y ago
  > This is why you have column headers? I'm not sure I can follow. You get an uuid from somewhere, probably external code that you cannot even look at. The uuid comes stringly-typed, let's say as json. Then you have no chance to know what type it is, you can only assume it is the correct type that you expect. Just putting "550e8400-e29b-11d4-a716-446655440000" into a person colum does not make it a person id. If you get instead "order-550e8400-e29b-11d4-a716-446655440000" as a typed-uuid, you know for sure that this is not a person id. It is an order id. Somebody made a mistake somewhere. You also know that you probably have to look in the order DB to debug what it actually refers to. > but to use it throughout your db eats up tons of space from both text encoding the id You dont need to put your uuid in this format into the db. You can add/remove the type before/after accessing the db.
  - SigmundA 6y ago
    Just putting "order-550e8400-e29b-11d4-a716-446655440000" does not make it an order id either, thats what foreign keys are for, mistakes can be made either way. If your sending id via json you should be using json to encode type either: { order:"550e8400-e29b-11d4-a716-446655440000" } Or if for some reason the value could contain multiple types: { thing: { t:"order", id:"550e8400-e29b-11d4-a716-446655440000" } } Even then just use: { thing: { order :"550e8400-e29b-11d4-a716-446655440000" } } This is redundant and not necessary adding overhead: { order: "order-550e8400-e29b-11d4-a716-446655440000" } Storing that in your db as json even worse (Mongo, JSONB), storing as varchar in normal column not much better. If your not storing ID with a type prefix in the db, then thats not the form of your id's that just the UI/encoding for them in your app which eliminates half the supposed advantage which was easy debugging say in db query tools. It also means you are parsing / deparsing "order-550e8400-e29b-11d4-a716-446655440000" somewhere in your db mapper code instead of just using your json or query string parser or protobuf or whatever, why?.
    - seppel 6y ago
      > Just putting "order-550e8400-e29b-11d4-a716-446655440000" does not make it an order id either, thats what foreign keys are for, mistakes can be made either way. I'm not talking about the DB level here, I'm talking about what goes over the wire or ends up in logs files. And if you are handing out the uuids to your consumers, you can be reasonable sure that you only get back the uuids you handed out. So if "order-550e8400-e29b-11d4-a716-446655440000" is not an order, it an error on your side and not on your clients side. > If your sending id via json you should be using json to encode type either: Yes and you should also not make any mistakes.
      - SigmundA 6y ago
        So it all comes down to less mistakes made with: order:"order-550e8400-e29b-11d4-a716-446655440000" vs order:"550e8400-e29b-11d4-a716-446655440000" Either one will error in a sane system that checks to make sure the UUID is actually in the db either one can have mishandling sending the wrong id, you just have some extra redundant bytes double confirming the key type while the actual ID will still have to verified. The nice thing about UUID over say ints is there should be no overlap, so it should be easy to confirm an error like that, double encoding the key from external apis, sure I guess a very slight reduction in time taken to verify an error, for logs aren't you logging the json with the key already? Of course this whole discussion was about an time order UUID's which are mostly useful just for DB's, if we are just talking about how ID's are formatted for external use in the app, well geez I thought that was what query strings and json was for but ok.

by seppel 6y ago

SigmundA 6y ago

This is why you have column headers? If you just want it to look that way in a text log, then sure prepend the type with the id wasting some space there, but to use it throughout your db eats up tons of space from both text encoding the id and repeating the column name in the data over and over.

StreamBright 6y ago
>> but to use it throughout your db eats up tons of space I think human resources and outages cost a lot more than disk space these days. If I can trade disk space for either of those I will do it in a blink of an eye.
- SigmundA 6y ago
  Not just disk space, larger index size mean less fits in caches and memory, more I/O etc. These are keys which are typically used constantly by an app in the db with joins etc. They are some of the hottest data typically and you want to avoid cache misses on them if possible.
seppel 6y ago
> This is why you have column headers? I'm not sure I can follow. You get an uuid from somewhere, probably external code that you cannot even look at. The uuid comes stringly-typed, let's say as json. Then you have no chance to know what type it is, you can only assume it is the correct type that you expect. Just putting "550e8400-e29b-11d4-a716-446655440000" into a person colum does not make it a person id. If you get instead "order-550e8400-e29b-11d4-a716-446655440000" as a typed-uuid, you know for sure that this is not a person id. It is an order id. Somebody made a mistake somewhere. You also know that you probably have to look in the order DB to debug what it actually refers to. > but to use it throughout your db eats up tons of space from both text encoding the id You dont need to put your uuid in this format into the db. You can add/remove the type before/after accessing the db.
- SigmundA 6y ago
  Just putting "order-550e8400-e29b-11d4-a716-446655440000" does not make it an order id either, thats what foreign keys are for, mistakes can be made either way. If your sending id via json you should be using json to encode type either: { order:"550e8400-e29b-11d4-a716-446655440000" } Or if for some reason the value could contain multiple types: { thing: { t:"order", id:"550e8400-e29b-11d4-a716-446655440000" } } Even then just use: { thing: { order :"550e8400-e29b-11d4-a716-446655440000" } } This is redundant and not necessary adding overhead: { order: "order-550e8400-e29b-11d4-a716-446655440000" } Storing that in your db as json even worse (Mongo, JSONB), storing as varchar in normal column not much better. If your not storing ID with a type prefix in the db, then thats not the form of your id's that just the UI/encoding for them in your app which eliminates half the supposed advantage which was easy debugging say in db query tools. It also means you are parsing / deparsing "order-550e8400-e29b-11d4-a716-446655440000" somewhere in your db mapper code instead of just using your json or query string parser or protobuf or whatever, why?.
  - seppel 6y ago
    > Just putting "order-550e8400-e29b-11d4-a716-446655440000" does not make it an order id either, thats what foreign keys are for, mistakes can be made either way. I'm not talking about the DB level here, I'm talking about what goes over the wire or ends up in logs files. And if you are handing out the uuids to your consumers, you can be reasonable sure that you only get back the uuids you handed out. So if "order-550e8400-e29b-11d4-a716-446655440000" is not an order, it an error on your side and not on your clients side. > If your sending id via json you should be using json to encode type either: Yes and you should also not make any mistakes.
    - SigmundA 6y ago
      So it all comes down to less mistakes made with: order:"order-550e8400-e29b-11d4-a716-446655440000" vs order:"550e8400-e29b-11d4-a716-446655440000" Either one will error in a sane system that checks to make sure the UUID is actually in the db either one can have mishandling sending the wrong id, you just have some extra redundant bytes double confirming the key type while the actual ID will still have to verified. The nice thing about UUID over say ints is there should be no overlap, so it should be easy to confirm an error like that, double encoding the key from external apis, sure I guess a very slight reduction in time taken to verify an error, for logs aren't you logging the json with the key already? Of course this whole discussion was about an time order UUID's which are mostly useful just for DB's, if we are just talking about how ID's are formatted for external use in the app, well geez I thought that was what query strings and json was for but ok.