Hablemos de los peligros de la generación automática de IDs en bases de datos. En este artículo compartiré mis experiencias y conocimientos adquiridos a lo largo de los años trabajando en múltiples proyectos que hacen uso intensivo de bases de datos. He tenido la oportunidad de evaluar diferentes estrategias de bases de datos y conocer sus ventajas e inconvenientes.
¿Cómo identificamos las entidades?
Al escuchar esta pregunta, por defecto tiendo a responder con un ID auto-incremental, que vendría a ser lo más rápido y sencillo. Siendo sinceros muchas veces esto termina siendo un error, ya que lo correcto sería parar en seco para pensar en lo siguiente:
«Depende... ¿Cual va ser la función de esta entidad? ¿Voy a tener un número determinado de registros (países), o pueden ser teóricamente infinitos (usuarios)? ¿Van a almacenar información sensible? ¿Voy a insertar una entidad cada dos días o varias por segundo?»
Dado que una vez respondamos estas preguntas podremos saber de manera certera si debemos delegar el proceso de identificación en manos de nuestro amigo el ID auto-incremental o merece la pena dedicar nuestro tiempo y recursos a cocinar una solución a medida.
Necesito una solución a medida, ¿qué opciones tengo?
¿Estas seguro? Permíteme tratar de venderte a mi querido ID auto-incremental.
IDs auto-incrementales
Cada vez que se agrega un registro, se le asigna un número consecutivo como ID (ej: 1, 2, 3…). Dicho número aumenta en +1 por cada nuevo registro, lo que garantiza que éste sea único. Además, no tienes que hacer nada para implementarlo. ¿Suena bien verdad? Desgraciadamente no es oro todo lo que reluce…
- Replicar la BBDD (tener varias instancias) se vuelve bastante más complicado.
- Los IDs anteriores y siguientes son fáciles de adivinar, es un posible agujero de seguridad.
- Insertar multiples registros de forma simultánea es un posible cuello de botella al tener que esperar para obtener un ID consecutivo cada registro, o intentar insertar dos entidades con el mismo ID en caso de tener varias instancias de BBDD.
- Puedes tener el mismo ID en múltiples tablas diferentes.
UUID (Universally Unique Identifier)
Cada nuevo registro es identificado mediante un número de 128 bits (ej: 550e8400-e29b-41d4-a716-446655440000) generado de forma aleatoria que prácticamente asegura que no van a existir 2 iguales. Parece que hemos dado en el clavo, ¿no?
Este tipo de identificadores tampoco son perfectos…
- Transmiten 0 información sobre la entidad que representan. Si tienes varias entidades que usan UUIDs como ID o si te encuentras un log con un ID no vamos a saber a qué entidad pertenece sin hacer una búsqueda en BBDD.
- Posiblemente el rango de objetos que permite este muy encima de nuestras necesidades (2^128)
- Los propios IDs no indican el orden, lo cual requiere que la entidad tenga otros campos para indicar su orden.
IDs custom
También podemos generar los IDs con un algoritmo propio, jugando con letras y números en función de nuestras necesidades. Por ejemplo tenemos la entidad user y decidimos que el identificador comience por una U seguida de 10 números aleatorios (U1234567890). ¡A la tercera va la vencida! Lo siento, pero esta vez no…
- Es muy probable que nuestro algoritmo no sea todo lo aleatorio que creemos y tengamos que crear mecanismos para comprobar que el ID no existe y generar otro en caso de que ya esté en uso.
- Seguramente nos hayamos quedado cortos y subestimemos nuestras necesidades, lo que hará que las colisiones sean mucho más habituales de lo que esperamos o tengamos que modificar el algoritmo y/o el formato de ID.
- Puede que apliquemos un exceso de ingeniería a nuestra solución intentando esquivar los problemas arriba mencionados y terminemos creando algo mucho más complejo de lo que necesitamos.
- Dependiendo del diseño del algoritmo, los propios IDs pueden no sugerir su orden, lo cual requiere que la entidad tenga otros campos para indicar su orden.
Entonces, ¿qué solución debemos aplicar?
Como pasa con casi todo en esta vida (ya hice un pequeño spoiler en el segundo párrafo), realmente depende… No hay una solución perfecta. En mi opinión debemos conocer las herramientas que tenemos a nuestro alcance junto con las fortalezas y las debilidades de éstas.
Si necesitas un MVP (con una deadline en dos semanas), seguramente usaría IDs auto-incrementales y encargarme de solucionar la deuda técnica en un futuro en caso de que surja. Si estamos trabajando en una solución más madura y prevemos que la entidad vaya a tener un alto rodaje, posiblemente use un ID custom. También he de reconocer que prefiero no tener más de una entidad representada por UUIDs, me gusta tener indicios de la entidad con la que estoy trabajando nada más ver el ID.
Para mí la solución ideal pasa por usar múltiples tipos de ID diferentes. Eso demuestra que le hemos dado el cariño necesario a cada entidad y nos hemos preocupado de que esté correctamente estructurada según los requisitos y sus casos de uso.
