4 ms·

This seems overly complicated. Why not generate an ID out of two numbers, one a server or thread ID and another that auto-increments? Assigning a unique number

by mark-r 12y ago

This seems overly complicated. Why not generate an ID out of two numbers, one a server or thread ID and another that auto-increments? Assigning a unique number to each entity that can generate IDs seems like a tractable problem, and the odds of generating a collision can be reduced to zero if you negotiate a new number when the counter wraps around.

riffraff 12y ago
UUIDv1 is in fact: server MAC Address+timestamp. UUIDv2 is instead: UID+MAC Address+timestamp The debate regarding the length is the same though.
JoeAltmaier 12y ago
UUID generation collision is essentially zero too. Any scheme you can contrive has the vulnerability that somebody else may choose the same roots as you, including yourself if you restart unexpectedly.
- mark-r 12y ago
  Certainly I agree that UUIDs aren't going to collide. But UUIDs were created to solve a problem most people don't have - how to ensure unique IDs when there is absolutely no communication between the parties generating the IDs. The article was suggesting one alternative to the UUID, and I suggested another.
  - JoeAltmaier 12y ago
    Sure but why? We have UUID's and good generators. Run with it. UUIDs solve a problem many, many people do have - identifying things over time and space - without having to even consider communication/coordination. That's a very powerful property.
    - mark-r 12y ago
      Again, I'm not arguing that UUIDs aren't a powerful tool. But the article points out two problems with them - they're inconveniently long when you expose them to the user, and they lead to a fragmented database because they're not generated in order. If those problems matter to you, then you look for an alternative. If they don't, then the UUID is the go-to solution.
      - JoeAltmaier 12y ago
        Very true. Some help: Inside a self-consistent database you might index the UUIDs and use the index internally to link them other places. Or something like that. Its work. If more use were made of UUIDs, databases would handle them better and that's probably going to happen.

by mark-r 12y ago

riffraff 12y ago

UUIDv1 is in fact: server MAC Address+timestamp. UUIDv2 is instead: UID+MAC Address+timestamp The debate regarding the length is the same though.

JoeAltmaier 12y ago

UUID generation collision is essentially zero too. Any scheme you can contrive has the vulnerability that somebody else may choose the same roots as you, including yourself if you restart unexpectedly.

mark-r 12y ago
Certainly I agree that UUIDs aren't going to collide. But UUIDs were created to solve a problem most people don't have - how to ensure unique IDs when there is absolutely no communication between the parties generating the IDs. The article was suggesting one alternative to the UUID, and I suggested another.
- JoeAltmaier 12y ago
  Sure but why? We have UUID's and good generators. Run with it. UUIDs solve a problem many, many people do have - identifying things over time and space - without having to even consider communication/coordination. That's a very powerful property.
  - mark-r 12y ago
    Again, I'm not arguing that UUIDs aren't a powerful tool. But the article points out two problems with them - they're inconveniently long when you expose them to the user, and they lead to a fragmented database because they're not generated in order. If those problems matter to you, then you look for an alternative. If they don't, then the UUID is the go-to solution.
    - JoeAltmaier 12y ago
      Very true. Some help: Inside a self-consistent database you might index the UUIDs and use the index internally to link them other places. Or something like that. Its work. If more use were made of UUIDs, databases would handle them better and that's probably going to happen.