Mejores prácticas de identificación para bases de datos

Question

Me preguntaba cuáles eran las mejores prácticas para crear y almacenar ID. Hace unos años, un profesor me habló de los peligros de un sistema de identificación mal construido, utilizando como ejemplo el número de la Seguridad Social. En particular, debido a que los SSN no tienen ninguna detección de error ... es imposible distinguir la diferencia entre una cadena de 9 dígitos y una SSN válida. Y ahora las agencias gubernamentales necesitan cosas como Apellido + SSN o Cumpleaños + SSN para realizar un seguimiento de sus datos y garantizar su verificación. Además, su número de seguro social es un tanto predecible según el lugar donde nació.

Ahora estoy construyendo una base de datos de usuario ... y en base a este consejo "userid mediumint auto_increment" sería inaceptable. Especialmente si planeo usar este ID como la identificación primaria para el usuario. (por ejemplo, si permito a los usuarios cambiar su nombre de usuario, entonces sería más difícil hacer un seguimiento del nombre de usuario que el ID de usuario numérico ... que requiere claves en cascada y demás). Los correos electrónicos cambian, los nombres de usuario pueden cambiar, las contraseñas cambian. .pero un usuario debe permanecer constante para siempre.

Claramente, auto_increment está diseñado solo para surrogate_keys. Es decir, es un acceso directo útil solo cuando ya tiene un mecanismo de identificación principal, pero no debe usarse como un "identificador innato" para los datos. Crear UUID aleatorio parece interesante, pero la aleatoriedad me apaga.

Y entonces pregunto: ¿cuáles son las mejores prácticas para crear un número de identificación de "clave principal"?

Answer 1

Está confundiendo la funcionalidad de la base de datos interna con los criterios de búsqueda externos.

Las claves sustitutas de incremento automático son útiles para el uso interno de la aplicación. Nunca le pase eso al usuario. La identificación de los objetos comerciales, ya sea un usuario o una factura, se realiza con información única sobre el objeto, como SSN, CCN o DOB. Use tanta información como sea necesario para identificar de manera única el objeto.

Recomiendo encarecidamente que si debe proporcionar algún valor de ID recientemente inventado a cada cliente, NO sea el campo en el que vincule todas las tablas de datos del cliente.

Answer 2

La mejor práctica es usar un número entero de incremento automático. No hay una razón real por la que no deba usarse como un "identificador innato". Proporcionará el uso más compacto en claves externas y búsquedas más rápidas. Casi cualquier otro valor puede cambiar y es inapropiado para usarlo como clave.

Answer 3

La comparación de SSN con enteros autoincrementados es de manzanas y naranjas. Personalmente, evito los GUID/UUID/UID a menos que haya tantos registros en la tabla que resulte ineficaz o irracional usar un número entero.

Es muy raro que encuentre una verdadera clave natural. Lo que parece único hoy puede cambiar mañana en función de los requisitos/leyes comerciales.

Answer 4

Esto es lo que las secuencias fueron diseñadas para resolver. Cree un objeto que pueda aumentarse atómicamente por inserción. En algunos DBs, el número se incrementa automáticamente y en otros es un objeto de secuencia, pero la idea es la misma, es decir, crea una clave que no puede entrar en conflicto y es única.

También los UUID como ID están bien y lo he usado anteriormente por razones especiales. ¿Por qué la aleatoriedad te "apaga"? Prácticamente no hay posibilidad de un conflicto.

Answer 5

Al final del día, la manera de verificar si un identificador de usuario dado es válido es el sistema mismo. Es decir, su sistema es la fuente autorizada para esos identificadores. ¿Es 555-45-9999 un SSN válido? La única forma de saberlo con certeza es que el Seguro Social lo busque y lo relacione con el nombre de la persona que dice tener ese número. Claro, podemos usar el esquema de identificador de SSN para plantear una suposición preliminar sobre si es válido. Sin embargo, solo una búsqueda en su sistema nos dirá con seguridad. La necesidad de dígitos de verificación surgiría en sistemas altamente distribuidos donde, por ejemplo, es posible que desee permitir que otras personas generen números respetados por su sistema (por ejemplo, empresas de envío que permiten a los clientes generar sus propios números de seguimiento). Dado que es su sistema el que generará los identificadores de manera automatizada, lo mejor que puede hacer un dígito de control es ayudar, de manera rudimentaria, con la validación de la entrada o búsqueda de datos.

Answer 6

Según nuestra conversación anterior en los comentarios, estoy publicando esto como una respuesta.Parece como si creyera que tener una ID aleatoria y única asignada a sus usuarios les proporcionaría la seguridad suficiente como para que pudieran renunciar a los métodos normales de autenticación.

En cualquier caso, estoy confundido por sus comparaciones entre datos seguros y autoincrementando, columnas de ID basadas en enteros en tablas de usuario. Estos dos tipos de datos nunca deben mezclarse. Su compañía de tarjeta de crédito no debe usar un CCN como clave principal en una tabla de base de datos, y el gobierno tampoco debe usar su nombre o SSN como clave principal en sus tablas de base de datos.

¿Por qué debería usted (o cualquiera) autenticar usuarios con solo conocimiento de algunos datos seguros? Las corporaciones ya no pueden autenticar a los usuarios según sus SSN, y sé que mi compañía de tarjetas de crédito no me identifica en función de mi CCN (especialmente porque tengo más de uno, y los números de tarjetas en las cuentas han cambiado varias veces).)

Incluso si implementó un UUID y generó un número aleatorio arbitrario, sigue siendo eso: un número . La autenticación de Active Directory usa GUID para sus ID, pero también requiere que los usuarios proporcionen nombres de usuario y contraseñas. Usar un tipo de datos más grande o más pequeño como columna de ID no significa que pueda lavarme las manos con otro tipo de autenticación o seguridad.