Crear una clave primaria secundaria en una base de datos para algunas tablas

A algunas de mis tablas quiero agregar "second_primary_key", que será uuid o alguna clave larga aleatoria. Lo necesito porque para algunas tablas no quiero exponer enteros a mi aplicación web. Es decir, en una página "/ facturas" tengo una lista de facturas y un enlace a "/ facturas /: id" donde: id es un número entero. No quiero que un usuario sepa cuántas facturas hay en mi sistema, por lo tanto, en lugar de "/ invoices / 123", quiero usar su "segunda_primera_clave" para que la URL sea "/ invoices / N_8Zk241vNa"

Lo mismo ocurre con otras tablas donde quiero ocultar la identificación real.

Me pregunto, ¿es esta una práctica común? ¿Cuál es la mejor manera de implementar esto?

¿Y cómo se llama esta técnica después de todo, para que pueda buscarla?

Puede agregar una columna UUID pero realmente no necesita (y no debería). Esta es una preocupación de la capa de presentación. No soñaría con decir, almacenar un valor de moneda de $ 1,999 y 1999.

Solo desea oscurecer el valor sobre la marcha para la aplicación. Puede hacer esto en la propia aplicación o como una vista de base de datos.

Como solo estamos hablando de un valor único, tal vez mire el cifrado de 2 vías, como AES o similar, cuanto más liviano, mejor.

El hash podría ser otra posibilidad: depende de si desea recuperar el número de factura, ya que el hash es una forma.

Tener una "clave primaria alternativa" es un concepto bien conocido en el modelado de bases de datos relacionales, se llama "clave alternativa" o, a veces, también "clave secundaria". El conjunto de "claves primarias potenciales" se denomina "claves candidatas". Ver https://beginnersbook.com/2015/04/alternate-key-in-dbms/

La forma en que implemente esto depende completamente de usted, especialmente si desea ocultar el número total de registros. No hay una "mejor manera", debe verificar sus requisitos, como el juego de caracteres permitido o útil, la longitud máxima, si desea que las ID distingan entre mayúsculas y minúsculas, si desea que sean legibles en una factura impresa, si alguien debe poder respetarlos en el teléfono sin errores, etc.

La mayoría de las facturas tienen un número de factura, que según la mayoría de las reglas de contabilidad debe ser secuencial o un contador puede no firmar los resultados del año o el IRS (o similar en su país) puede querer hacer una auditoría completa de sus pestañas.

Un usuario podría deducir del número de factura cuántos clientes ha atendido, o cuánto tiempo pasó antes de que cambiara la estrategia de numeración en las facturas.

La cantidad de facturas almacenadas en la base de datos no es una medida del total general de sus facturas. Hay otros medios para averiguarlo, incluida la solicitud de sus informes anuales de la Cámara de Comercio.

Sin embargo, bloquearía la factura detrás de una pantalla de inicio de sesión de usuario, para que no todos puedan solicitarla. Luego, en el inicio de sesión del usuario, pueden usar una metodología ajax para solicitar sus facturas pendientes, etc. Esto asegura sus datos, oculta la URL por ajax (generalmente nadie puede molestarse en ver los detalles de cómo se construye la solicitud ajax) , y usted controla cómo se muestran y ofrecen los datos.

Es posible que pueda usar hashids para esto, está diseñado para resolver exactamente este escenario.

Codificará su ID de base de datos en un hash corto (similar a la URL de un video de YouTube), y no requerirá que agregue ninguna clave secundaria a su tabla.

Puede crear otra clave única, pero no debería. No por la razón dada. Hay formas más simples de ocultar los tamaños de las mesas.

El almacenamiento N_8Zk241vNacuesta 12 bytes por fila en la tabla e incluso más en el índice. Eso es bastante derrochador para lo que necesitas.

Cifrar el número entero idno le cuesta espacio y casi nada en el tiempo de ejecución. Cómo lo haga depende de su lenguaje de programación y / o su base de datos.

Tenga en cuenta que con AES obtiene un número entero de 128 bits, lo que significa 22 caracteres en base64, probablemente más de lo que desea. Un cifrado con un tamaño de bloque de 64 como DES o 3DES le proporciona 11 caracteres, tal como lo desea.

Use diferentes claves para diferentes tablas.

Si todo lo que necesita es ocultar los tamaños de las tablas, puede usar una secuencia común para todas las tablas. Tenga en cuenta que puede ser un cuello de botella si hay inserciones frecuentes en muchas de sus tablas. Con algo como Hibernate y un algoritmo Hi-Lo, este problema desaparece.

En mi humilde opinión, la creación de dos claves principales diferentes no es posible. Por supuesto, puede poner ese uuid en una base de datos para tenerlo como "alias" para la clave primaria actual. Puede colocar un índice sobre esa columna con una restricción única, pero la clave primaria es (desde su esencia) única dentro de una sola tabla. Puede haber una clave primaria compuesta, pero eso no es lo que está buscando.

Así que sugiero ponerlo allí, pero tenerlo solo con índice. Puede crear un componente de manejo para consultar datos por PK, así como otra columna única. Cuando maneje la solicitud de "/ facturas / ..." simplemente verifique el parámetro; si es entero, busque el ID, de lo contrario, busque uuid. O puede tener la búsqueda uuid como alternativa cuando la búsqueda de ID no encontró nada.

Y sobre la generación de algunos uuids "aleatorios": ¿Por qué no algo como "tomar ID, agregar CONSTANT, convertir a hexadecimal". La iniquidad de la ID proporcionará la unicidad del líquido, el número hexadecimal es más difícil de leer para los mortales normales + agregar constante evitará tener un líquido como 00000001.

Si ambas teclas apuntan al mismo hecho, y nunca chocarían. ¿Por qué no deriva la otra clave de la original utilizando alguna función escalar que crearía un código hash personalizado de su clave original?

alternativamente, puede crear una tabla de mapeo anexo, que almacenaría ambas versiones de la clave. esta tabla actuará como un diccionario para buscar la clave secundaria.

Según tengo entendido, las claves son índices implícitos, y cuanto más agregue índices, las inserciones más lentas serán.

Otro enfoque para su caso de uso particular es que, en lugar de modificar la base de datos y la aplicación, puede crear una ruta personalizada a las facturas para que / invoices /: f (id) donde f (id) sea alguna función de la identificación.

La ruta personalizada es responsable de asignar una solicitud a la acción correcta del lado del servidor.

Es una práctica totalmente aceptable, también llamada 'Clave alternativa' (AK). Básicamente, el AK es otro índice único o restricción única.

Incluso puede crear restricciones de clave externa basadas en su AK.

Un posible caso de uso es como lo que explicó: tiene un PK agrupado en un número de identidad cada vez mayor, pero no desea que este número se muestre o use como criterio de búsqueda, porque simplemente se puede adivinar. Entonces, además, tiene un identificador único aleatorio o un número de referencia como AK, y esa es la identificación que presenta al usuario

Hay varios tipos de claves / índices. Una clave principal es un índice único especial, y como dicen las respuestas, ciertamente puede crear otra clave única. Y estoy de acuerdo en que es mejor no exponer los elementos internos de su base de datos a menos que haya una muy buena razón.

Dado que la pregunta está en el contexto de las facturas y los números, podría valer la pena investigar cómo la industria contable espera que se vean los números de las facturas: http://smallbusiness.chron.com/assign-invoice-numbers-52422.html

Puede parecer complicado tener una identificación interna que sea una clave principal y otro campo único con el número de factura visible de la aplicación / cliente. Pero no es tan impuro cuando, digamos un año después, el cliente quiere adoptar un nuevo esquema de numeración de facturas. En ese caso, no alteraría la identificación interna y sus relaciones en otras tablas para volver a numerar toda la bola de cera. Mantendría su identificación interna tal como está y volvería a numerar el número de factura no interna.

Lo ideal es que intentes no vincular tablas en claves / claves externas que puedan cambiar, y mantener tus tablas y relaciones internas transparentes para la capa de la aplicación.

Ve a por ello.

Esto no es diferente de un campo "babosa" que los artículos de blog y similares a menudo tienen: una forma única de referirse al registro de la base de datos separado de la clave primaria, apto para su uso en una URL. Nunca escuché a nadie discutir contra ellos.