He visto esto una y otra vez durante los últimos años, la gente deja que la base de datos establezca el ID o Clave Primaria de una tabla desde la base de datos, a primera vista esto suena simple y todo el mundo sabe que debe dejar que la base de datos haga el trabajo pesado, con un número de "Secuencia" numérico necesita dejar que la base de datos haga el trabajo ya que puede haber múltiples aplicaciones o hilos creando nuevos registros en la tabla. ¡NO LO HAGAS!
En primer lugar, si necesitas fusionar dos bases de datos que ahora tienen los mismos valores de ID de clave primaria para la misma tabla, estás jodido. Tienes que idear un esquema para cambiar los ID, tal vez añadiendo 10.000 a cada ID, ¿y si tienes más de 10.000 filas? También hay que actualizar todos los registros de los hijos, lo que no es tan fácil si hay restricciones definidas en la base de datos.
En segundo lugar, si expones tus datos como una API entonces tarde o temprano que va a pasar, que acaba de abrir su sistema a lo que los hackers les encanta ver. Me explico:
Puedo iniciar sesión y acceder a mi información, tal vez mis compras de la siguiente manera:
GET https://secureserver.com/puchases/123
¿Simple verdad? Obtengo las compras para el ID de usuario 123, pero ¿qué pasa si haces otra llamada:
GET https://secureserver.com/puchases/100
Ahora estás recibiendo las compras para el usuario 100, que no es quien eres, que acaba de permitir que un hacker externo para obtener acceso a su base de datos. Digamos que se trata de algo personal como un Chia Pet, ahora el hacker sabe que el usuario ID 100 ha comprado un Chia Pet.
Otra llamada a una API para el usuario ID 100 se puede ver que el usuario es Elon Musk. ¿Realmente queremos que el mundo sepa que Elon Musk tiene un fetiche por las Chia Pet? Acabas de exponer sus datos seguros y perderá la confianza de sus clientes, pero podría ser peor, la API también podría exponer los días de nacimiento, direcciones, números de la Seguridad Social, tal vez incluso el número de tarjeta de crédito (si no sigue las normas PCI).
Ahora echemos un vistazo al uso de un UUID para la llamada.
GET https://secureserver.com/puchases/4a21-64E2-4514-623a
Mucho más seguro ya que añadiendo un número aquí o allá probablemente no se accedería a ninguna información.
Por lo tanto, la moraleja de la historia es ¡NO UTILIZAR INTEGERS para los ID's de las CLAVES primarias NUNCA!
Ten en cuenta que el uso de un UUID para la clave que significa que ahora está utilizando una cadena es un gran avance, ahora puede combinar dos bases de datos sin ningún problema.
En los viejos tiempos (hace 10 años) las bases de datos eran lentas y a la gente se le decía que no usara cadenas para las claves debido al rendimiento, ahora todas las bases de datos utilizan claves hash en cierta medida por lo que ya no hay una preocupación por el rendimiento.
Todavía tienes el problema de seguridad de la autorización, se supone que su sistema tiene la autenticación resuelta para que pueda saber quién ha iniciado sesión en el sistema. También es necesario asegurarse de que sólo los usuarios autorizados pueden acceder a sus recursos, esto significa que cuando alguien intenta acceder a un usuario o compras y estos no le pertenecen recibe un error.
Hay que tomárselo en serio, ha habido muchos hackeos utilizando esta sencilla técnica, algunos de los mayores minoristas de EE.UU. expusieron datos de clientes de esta manera. Incluso algunos de los mayores guardianes de contraseñas de seguridad tuvieron los mismos problemas y fueron pillados con los pantalones bajados. No deje que su empresa sea la próxima víctima. Arréglelo hoy mismo.
