UUID vs ID para la API #12
KebPericles
started this conversation in
General
Replies: 1 comment 1 reply
-
Probablemente se implemente la idea del truncado de SHA-1, se podría hashear la hora del commit y posteriormente truncar el hash a 64 bits, lo cual según esto nos deja con 2^32 ids antes de que empiece a colisionar. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Tengo la duda de si el uso de UUID puede degradar considerablemente el rendimiento a largo plazo, inicialmente se me ocurrio usar UUID porque sería muy sencilla la implementación para los formularios, unicamente llamo a la función e incluyo el UUID en el formulario sin mayor preocupación. Este enfoque me pareció superior al ID porque no necesitaba guardar una variable para saber el último ID, también sobre el hash porque unicamente se me ocurrió hashear el formulario (lo cual no sería malo ahora que lo pienso). En fin, acá documentaré la investigación para saber que usar.
Iniciando con esta pregunta de stackoverflow: https://stackoverflow.com/questions/2365132/uuid-performance-in-mysql
Que en uno de los comentarios me mandó a esta otra: https://krow.livejournal.com/497839.html
A su vez en ese blog encontré esta discusión: https://krow.livejournal.com/497839.html#t1932975
Esto me lleva a pensar en cuál es el problema de usar UUID para la API, si realmente no es como que el repositorio sea algo de lo que deba preocuparme por su velocidad, tal vez al momento de llevarlo a otra aplicación en la que sí necesite indexarlo podría haber problema. Probablemente como lo sugiere la discusión unicamente con el truncado de SHA-1 sea suficiente para una aplicación pequeña como esta, que además no tiene ninguna funcionalidad de distribución de la BD o relacionado que pueda introducir problemas de colisión.
Beta Was this translation helpful? Give feedback.
All reactions