2012-02-21 25 views
5

Estoy ocupado con el diseño de la base de datos de un nuevo proyecto, y no estoy seguro de si usar UUID o ID de incremento automático de tabla normal.¿Cuándo es apropiado usar UUID para un proyecto web?

Hasta ahora, los sitios que he construido se han ejecutado en un único servidor, y el tráfico muy intenso nunca ha sido motivo de gran preocupación. Sin embargo, esta aplicación web eventualmente se ejecutará simultáneamente en varios servidores, servirá una API y necesitará procesar miles de solicitudes por segundo, y quiero asegurarme de que el diseño que elijo ahora no paralice ninguna de esas posibilidades más adelante.

Tengo mis sospechas, por supuesto, y deben ser claras a través de la forma en que formulé mi pregunta, pero me gustaría saber de quienes tienen más experiencia qué problemas puedo encontrar más adelante si lo hago o no tengo UUID, y en lo que realmente debería basar mi decisión.

Así, en definitiva: ¿Cuáles son las consideraciones que debería dar a decidir si debe o no utilizar UUID para todos los modelos de bases de datos, por lo que cualquier objeto puede ser identificada por una cuerda, y cuando es apropiado utilizar esto como la clave principal, en lugar de auto-incremento tabla por tabla?

Nota: He visto this question (When are you truly forced to use UUID as part of the design?), y leer todas las respuestas, pero en su mayoría contesto "¿Cómo rara vez, chocan UUID", en lugar de "¿Cuándo es apropiado usarlos".

Respuesta

2

Una consideración que he utilizado al decidir sobre UUID frente a identificadores de incremento automático es si van a ser visibles para el usuario, y si es así, si quiero que los usuarios sepan cuántos tengo de esa tabla . Por ejemplo, si no quisiera hacer público el número de usuarios registrados que tiene mi sitio, no asignaría identificadores de usuario de incremento automático.

Y para abordar otro punto específico que ha planteado, aún es posible usar identificadores de autoaumento con varios servidores (aunque no con el MySQL incorporado). Solo necesita iniciar todos los identificadores en diferentes desplazamientos e incrementarlos en consecuencia. Es decir, si tuviera 3 servidores, podría iniciar el servidor A en 1, el servidor B en 2 y el servidor C en 3, y luego incrementar los identificadores en 10 cada vez en lugar de 1. De esta forma, podría garantizar que no haya colisiones.

Y, por último, lo último que considero es cuán importante es el rendimiento para mi aplicación. Los enteros son mucho más fáciles de indexar que los UUID basados ​​en cadenas, por lo que los índices son más pequeños, se buscan más rápidamente, etc.

1

Los UUID o GUID pueden ser muy útiles especialmente para la web. Si usa valores de incremento automático para almacenar UserId, cualquiera puede ver el origen de sus páginas web y ver la simplicidad de su uso. Podrían probar cualquier valor entero para obtener datos que no deberían ver.

Los GUID no se crean en ningún formato secuencial, por lo tanto, si los crea uno después del otro, la secuencia no puede adivinarse fácilmente.

No creo que sea necesario usar GUID para datos de tipo de búsqueda simple como ColorId 1 = Azul, 2 = Rojo, 3 = Verde.

Los GUID también son muy útiles para la administración de sesión y estado.

Esa es mi $ 0.02

Cuestiones relacionadas