database - unico - ¿Cuál es su opinión sobre el uso de UUID como identificadores de filas de bases de datos, especialmente en aplicaciones web?
spatie binary uuid (14)
Siempre he preferido utilizar enteros largos como claves principales en las bases de datos, por simplicidad y velocidad (supuesta). Pero cuando REST un esquema de URL similar al de REST o Rails para instancias de objetos, entonces termino con URLs como esta:
http://example.com/user/783
Y luego se supone que también hay usuarios con identificaciones de 782, 781, ..., 2 y 1. Suponiendo que la aplicación web en cuestión es lo suficientemente segura como para evitar que las personas ingresen otros números para ver a otros usuarios sin autorización, una La simple clave sustituta asignada secuencialmente también "filtra" el número total de instancias (más antiguas que esta), en este caso los usuarios, que podrían ser información privilegiada. (Por ejemplo, soy el usuario n. ° 726 en stackoverflow).
¿Sería un UUID / GUID una mejor solución? Entonces podría configurar URLs como esta:
http://example.com/user/035a46e0-6550-11dd-ad8b-0800200c9a66
No es exactamente conciso, pero hay menos información implícita sobre los usuarios en exhibición. Claro, huele a "seguridad a través de la oscuridad" que no sustituye a la seguridad adecuada, pero parece al menos un poco más segura.
¿Vale la pena el costo y la complejidad de implementar UUID para las instancias de objetos direccionables por la web? Creo que todavía me gustaría usar columnas enteras como PK de base de datos solo para acelerar las uniones.
También está la cuestión de la representación en la base de datos de los UUID. Sé que MySQL los almacena como cadenas de 36 caracteres. Postgres parece tener una representación interna más eficiente (¿128 bits?) Pero yo no lo he probado. Alguien tiene alguna experiencia con esto?
Actualización: para aquellos que preguntaron sobre el uso del nombre de usuario en la URL (por ejemplo, http://example.com/user/yukondude ), eso funciona bien para las instancias de objetos con nombres que son únicos, pero ¿qué pasa con los trillones de web? ¿Objetos de la aplicación que realmente solo se pueden identificar por número? Pedidos, transacciones, facturas, nombres de imágenes duplicados, preguntas de stackoverflow, ...
¿Por qué acoplar su clave principal con su URI?
¿Por qué no hacer que su clave URI sea legible para el ser humano (o indescifrable, según sus necesidades), y su índice principal basado en enteros, de esa manera obtenga lo mejor de ambos mundos? Una gran cantidad de software de blog lo hace, donde la identificación expuesta de la entrada se identifica con un ''slug'', y la identificación numérica está oculta dentro del sistema.
El beneficio adicional aquí es que ahora tiene una estructura de URL realmente buena, lo cual es bueno para SEO. Obviamente para una transacción esto no es algo bueno, pero para algo como , es importante (ver URL arriba ...). Obtener la singularidad no es tan difícil. Si realmente está preocupado, guarde un hash de la babosa dentro de una mesa en algún lugar, y haga una búsqueda antes de la inserción.
editar: no usa el sistema que describo, ver el comentario de Guy a continuación.
Creo que este es uno de estos temas que provocan debates cuasirreligiosos, y es casi inútil hablar de él. Solo diría que uses lo que prefieras. En el 99% de los sistemas, no importa qué tipo de clave use, por lo que los beneficios (indicados en las otras publicaciones) de usar un tipo sobre el otro nunca serán un problema.
Creo que usar un GUID sería la mejor opción en su situación. Ocupa más espacio, pero es más seguro.
En lugar de URL como esta:
http://example.com/user/783
Por qué no tener:
http://example.com/user/yukondude
¿Cuál es más amigable para los humanos y no filtra esa pequeña información?
Lo intenté tanto en aplicaciones web reales.
Mi opinión es que es preferible usar números enteros y tener URLs cortas y comprensibles.
Como desarrollador, se siente un poco horrible ver números enteros secuenciales y saber que cierta información sobre el conteo total de registros se está filtrando, pero honestamente, a la mayoría de la gente probablemente no le importa, y esa información nunca ha sido realmente crítica para mis negocios.
Tener urls UUID feas y largas me parece mucho más desagradable para los usuarios normales.
No creo que un GUID te brinde muchos beneficios. Los usuarios odian las URL largas e incomprensibles.
Cree una ID más corta que pueda asignar a la URL, o aplique una convención de nombre de usuario única ( http://example.com/user/brianly ). Los chicos de 37Signals probablemente se burlarían de ti por preocuparte por algo como esto cuando se trata de una aplicación web.
Por cierto, puede obligar a su base de datos a comenzar a crear ID enteros a partir de un valor base.
No puedo decir sobre el lado web de su pregunta. Pero los uids son geniales para aplicaciones de n niveles. La generación PK se puede descentralizar: cada cliente genera su propio pk sin riesgo de colisión. Y la diferencia de velocidad es generalmente pequeña.
Asegúrese de que su base de datos sea compatible con un tipo de datos de almacenamiento eficiente (16 bytes, 128 bits). Por lo menos, puedes codificar la cadena de uuid en base64 y usar char (22).
Los he usado extensamente con Firebird y lo recomiendo.
Por lo que vale, he visto un procedimiento almacenado de larga ejecución (9+ segundos) caer a unos pocos cientos de milisegundos de tiempo de ejecución simplemente al cambiar de claves primarias GUID a enteros. Eso no quiere decir que mostrar un GUID sea una mala idea, pero como otros han señalado, unirse a ellos e indexarlos, por definición, no va a ser tan rápido como con enteros.
Puede usar un número entero que esté relacionado con el número de fila, pero no es secuencial. Por ejemplo, podría tomar los 32 bits de la ID secuencial y reorganizarlos con un esquema fijo (por ejemplo, el bit 1 pasa a ser el bit 6, el bit 2 pasa a ser el bit 15, etc.).
Este será un cifrado bidireccional, y estará seguro de que dos ID diferentes siempre tendrán encriptaciones diferentes.
Obviamente, sería fácil de decodificar, si uno se toma el tiempo para generar suficientes ID y obtener el esquema, pero, si entiendo correctamente su problema, solo quiere no dar información demasiado fácilmente.
Puedo responderte que en el servidor SQL si usas un tipo de identificación uniqueidentifier (GUID) y usas la función NEWID () para crear valores obtendrás una fragmentación horrible debido a las divisiones de página. La razón es que al usar NEWID () el valor generado no es secuencial. SQL 2005 agregó la función NEWSEQUANTIAL () para remediar
Una forma de seguir usando GUID e int es tener un guid y un int en una tabla para que la guía se corresponda con el int. el guid se usa externamente pero el int internamente en el DB
por ejemplo
457180FB-C2EA-48DF-8BEF-458573DA1C10 1
9A70FF3C-B7DA-4593-93AE-4A8945943C8A 2
1 y 2 se usarán en las uniones y las guías en la aplicación web. Esta tabla será bastante estrecha y debe ser bastante rápida para consultar
Siempre que use un sistema DB con almacenamiento eficiente, HDD es barato en estos días de todos modos ...
Sé que los GUID''s pueden ser fáciles de trabajar algunas veces y vienen con un poco de sobrecarga de consultas; sin embargo, desde una perspectiva de seguridad, son un salvador.
Pensando en la seguridad por oscuridad que encajan bien cuando se forman URIs oscuros y construyendo DB normalizados con seguridad definida por Table, Record y Column, no se puede equivocar con los GUID, intente hacer eso con id''s basados en enteros.
También depende de lo que te importa para tu aplicación. Para las aplicaciones de n niveles, los GUID / UUID son más fáciles de implementar y son más fáciles de transportar entre diferentes bases de datos. Para producir claves enteras, algunas bases de datos admiten un objeto de secuencia de forma nativa y algunas requieren una construcción personalizada de una tabla de secuencias.
Las claves enteras probablemente (no tengo números) proporcionan una ventaja para el rendimiento de la consulta y la indexación, así como para el uso del espacio. La consulta directa de DB también es mucho más fácil usando claves numéricas, menos copiar y pegar ya que son más fáciles de recordar.
Trabajo con un sistema de gestión de estudiantes que usa UUID en forma de un entero. Tienen una mesa que contiene la siguiente identificación única.
Aunque esta es probablemente una buena idea desde un punto de vista arquitectónico, dificulta el trabajo diario. A veces hay una necesidad de hacer inserciones masivas y tener un UUID lo hace muy difícil, por lo general requiere escribir un cursor en lugar de una simple instrucción SELECT INTO.
Usamos GUIDs como claves principales para todas nuestras tablas, ya que también funciona como el RowGUID para la replicación del servidor MS SQL. Lo hace muy fácil cuando el cliente abre de repente una oficina en otra parte del mundo ...