¿Debería exponerse una clave sustituta a un usuario?

A menudo, en una tabla que no tiene una clave natural, sigue siendo útil para que los usuarios puedan tener un identificador generado de forma única. Si la tabla tiene una clave primaria sustituta (y, en tal caso, es de esperar), ¿se debe exponer esa clave al usuario o se debe utilizar otro campo para ese propósito?

Una razón para no exponer la clave sustituta es que ahora no puede realizar operaciones que preserven la relación entre los registros, sino cambiar los valores clave, como ciertos tipos de eliminación / reinserción, muchos métodos para copiar datos de una base de datos a otro, etc.

La principal ventaja de exponer la clave sustituta es la simplicidad de usar un campo que tiene de todos modos.

¿En qué circunstancias es mejor exponer directamente la clave sustituta a los usuarios?

Debe estar preparado para cualquier identificador que esté expuesto a los usuarios / clientes que necesitan ser cambiados, y cambiar la identidad de una fila en una base de datos y propagar ese cambio a todas las claves foráneas es solo pedir que se rompan los datos.

Si los datos no tienen una clave comercial natural, puede agregar un campo adicional para un "identificador comercial". Esto debe optimizarse para los procesos para los que se utiliza. La entrada del teclado telefónico solo significa numérico. Por teléfono / verbal significa evitar símbolos de sonido similares (B / D, M / N, etc.). Incluso puede autogenerar alguna frase fácil de recordar ("gelatina verde").

El efecto de esto es que la empresa luego puede cambiar la forma en que quieren referirse a los registros, y el único cambio en el esquema de datos es agregar una nueva columna para ese estilo de identificación o transformar los identificadores que ya existen. El cambio no se propaga a través de toda la base de datos, y aún tiene una identificación (el sustituto) que es válida con el tiempo.

En resumen, evitaría exponer claves sustitutas a los usuarios. Como señalan los comentarios, las claves sustitutas casi nunca deberían cambiar. Por el contrario, las empresas quieren cambiarlo todo. Si se expone la clave sustituta, es solo cuestión de tiempo antes de que la empresa quiera cambiarla.

Como nota al margen, cuando digo "exponer" aquí, me refiero a darle la clave al usuario con la expectativa de que la use directamente (como llamar para solicitar asistencia con su número de pedido).

En algunos casos, se esperan claves sustitutas y tienen sentido para los usuarios. Mi ejemplo favorito es el "número de pedido". El número de pedido no es realmente una clave natural: una clave natural puede ser la marca de tiempo más el usuario, o tal vez más que eso si espera que los usuarios generen más de un pedido dentro de la granularidad de su marca de tiempo.

No obstante, los usuarios entienden y esperan la conveniencia de un número de pedido. No hay ningún daño y mucho valor si les informa a los usuarios sobre ellos.

Por otro lado, algunas claves sustitutas no tienen sentido para un usuario. Claro, mi compañía de seguros de salud tiene una clave sustituta que me identifica según mi identificación de miembro, fecha de nacimiento, compañía, etc., pero no me importa eso, me importa la información de mi tarjeta (que a menudo incluye identificadores basados en mi empleador y no son únicos en todo el universo ... De ahí la clave sustituta en la compañía de seguros).

Solo debe exponer una clave sustituta si es un GUID / UUID * generado correctamente. La exposición de claves sustitutas secuenciales es el número 4 en los 10 principales problemas de seguridad de OWASP.

* En la práctica, es mejor suponer que no se generó correctamente para estos fines a menos que sepa que fue creado por un generador de números aleatorio o pseudoaleatorio criptográficamente seguro.

Si una tabla no tiene clave natural, las claves sustitutas permiten filas como esta.

surrogate_key  some_name
--
1              Wibble
2              Wibble
...
17             Wibble
...
235            Wibble

Llamaría a estas claves artificiales en lugar de claves sustitutas, pero esa distinción no es importante para esta pregunta.

Ahora, suponiendo que hay datos importantes que hacen referencia a estas claves sustitutas a través de claves externas, ¿cómo sabrían los usuarios finales qué fila actualizar si no conocen los valores de las claves sustitutas?

En palabras simples:

• Los sustitutos deben estar ocultos para el usuario.
• Debe exponer alguna otra clave de candidato comercial al usuario.
• Si no existe otra clave candidata, debe mostrar la PK. Pero en este caso, el PK no se considera un sustituto ya que no es un sustituto de otra columna.

SÓLO debe exponer un campo a un usuario que le brinde información útil, ya sea directamente o al informarle defectos.

por el contrario, SIEMPRE debe exponer las "claves primarias sustitutas" cuando son el medio principal para identificar un registro (simple o complejo) para una interacción que realiza el usuario.

No debería importar si expone las claves o no al usuario final. Su aplicación debe realizar la autorización necesaria de tal manera que simplemente conocer una identificación de pedido, por ejemplo, no puede permitirles acceder a algo a lo que normalmente no tendrían acceso.

advertencia: esto supone una aplicación basada en web o de n niveles donde la autorización del lado del servidor es posible / factible. Si tiene una aplicación VB que está ejecutando directamente SQL, ese es un problema completamente diferente.