7
¿Cuáles son las desventajas de usar GUID? ¿Por qué no usarlos siempre por defecto?¿Por qué no siempre usar GUID en lugar de ID enteros?
A
Respuesta
15
Los enteros se unen mucho más rápido, por ejemplo. Esto es especialmente importante cuando se trata de millones de filas.
Para dos, los GUID ocupan más espacio que los enteros. De nuevo, muy importante cuando se trata de millones de filas.
En tercer lugar, los GUID a veces toman diferentes formatos que pueden causar interrupciones en las aplicaciones, etc. Un entero es un número entero, de principio a fin.
Se puede encontrar un aspecto más en profundidad here, y en Jeff's blog.
+1
Tarde en el juego que sé. Todavía vale la pena señalar que un GUID está guardado de 16 bytes o es incorrecto. Un entero en SQL Server tiene 4 bytes, pero no todos los enteros. Esto varía una cantidad justa por idioma y plataforma. –
9
Los GUID son cuatro veces más grandes que un int, y dos veces más grandes que un bigint.
Los GUID son realmente difíciles de observar si está intentando solucionar problemas de tablas.
1
GUID son grandes y lentos en comparación con enteros - por lo que usarlos cuando se necesitan, evitan ellos cuando no son necesarios, es tan simple como eso!
4
GUIDS puede simplificar la generación de claves con anticipación, o generar claves fuera de línea, o en un clúster, sin riesgo de colisión. También puede haber un pequeño beneficio de seguridad, con todas las claves siendo indescifrable.
La desventaja es que es más difícil de leer/escribir y en muchas de sus tablas puede que luego se dé cuenta de la necesidad de volver y generar claves para todos. También distribuirán uniformemente sus registros en una tabla, lo que puede hacer que sea más lento consultar múltiples registros que se insertaron más o menos al mismo tiempo que tener una clave de autonumeración donde los registros estén en orden de tiempo insertado.
0
El mayor golpe de rendimiento que verá con los GUID ya que una clave principal/en clúster es la inserción de registros en tablas grandes. Puede ser una tarea pesada para indexar desde su clave caerá en algún punto intermedio
4
Kimberly L. Tripp: GUIDs as PRIMARY KEYs and/or the clustering key
¿Ha leído los enlaces relacionados en el lado derecho?
+2
Buen artículo ... –
11
Los GUID son geniales desde el punto de vista de un programador: tienen la garantía de ser (casi) únicos, así que ¿por qué no usarlos en todas partes?
Si se mira desde la perspectiva de DBA y desde el punto de vista de la base de datos, al menos para SQL Server, hay algunas cosas a considerar:
- GUID como clave primaria (que es responsable de identificar de forma única una sola fila en su tabla) podría estar bien, después de todo, son únicos, ¿verdad?
- sin embargo, SQL Server también tiene el concepto de la clave de agrupamiento, que ordena físicamente los datos en su tabla; Si no sabe nada de esto y no hace nada explícitamente, su clave principal se convierte en su clave de agrupamiento.
Kimberly Tripp - experto mundialmente conocido en la indexación de SQL Server y el rendimiento - tiene un gran número de publicaciones en el blog acerca de por qué un GUID como clave de agrupación es una muy mala idea - echa un vistazo a su blog on indexes.
En particular, sus mejores prácticas para una clave de agrupación son:
- estrecha
- estática
- única
- cada vez mayor
GUID son normalmente estática y única - pero no son ni estrechos (16 byte vs. 4 byte para INT) ni nunca aumentan. Debido a su naturaleza, son únicos y (pseudo) aleatorios.
La parte estrecha es importante porque la clave de agrupamiento se agregará a todas y cada una de las páginas de índice para cada índice no agrupado de su tabla, y si tiene algunas de ellas, y unas pocas filas en su tabla, esto equivale a una pérdida masiva de espacio, y no solo en su disco, sino también en la RAM de su SQL Server.
La parte cada vez mayor es importante, porque la aleatoriedad de los GUID provoca una gran fragmentación en los índices, lo que afecta negativamente a su rendimiento. Incluso el newsequentialid() de SQL Server 2005 y versiones posteriores en realidad no crean GUID secuenciales por todos lados: son secuenciales por un tiempo y luego hay un salto de nuevo, lo que provoca fragmentación (menos que GUID totalmente aleatorios, pero aún así).
Así que en general, si realmente está preocupado con el rendimiento de su servidor SQL, using GUIDs as a clustering key es una muy mala idea: use INT IDENTITY() en su lugar, posiblemente usando un GUID como la clave principal (no agrupada) si realmente tiene que hacerlo
Marc
+1
Acepto que nunca se debe usar un GUID como clave principal. Sin embargo, los GUID son esenciales y deben usarse cuando los objetos de entidad (en el mismo dominio) se diseminan a través de múltiples instancias. –
0
El uso de GUID como clave primaria el tiempo dará lugar a su base de datos de estrellarse debido a que la unidad se vuelve demasiado fragmentado. Esta es una condición conocida como golpeteo.
1
Esta respuesta NO excluye la idea de utilizar INT como clave principal. Está destinado principalmente a señalar CUÁNDO es útil una guía.
Aquí hay una gran (corto) ARTICULO:
http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html
Explicado ...
utilizo guids DB para cualquier entidad de tipo (común) que puede necesitar ser exportado o compartida con otro Instancia de DB De esta forma, tengo un marcador de ADN (es decir, el guid) que se puede utilizar para diferenciar entre objetos "similares" del mismo tipo de entidad.
Por ejemplo, imaginemos que dos instancias de base de datos tienen una tabla llamada PROJECT. Si los dos proyectos comparten el mismo nombre o número, es difícil distinguir cuál es cuál. Sin embargo, al usar GUID puedes distinguir fácilmente entre 2 proyectos y de dónde vienen ... incluso cuando tienen muchos valores similares entre ellos. Esto parece imposible ... pero en realidad puede ocurrir y sucede.
Cuestiones relacionadas
- 1. ¿Por qué no debería usar ID de estilo con CSS?
- 2. ¿Por qué usar enteros menores que 32 bits?
- 3. de desbordamiento de enteros - ¿Por qué no
- 4. ¿Por qué usar var en lugar del nombre de clase?
- 5. ¿Por qué usar id cuando podemos usar NSObject?
- 6. ¿Por qué no es aconsejable usar attach() en R, y qué debería usar en su lugar?
- 7. ¿Por qué debería usar var en lugar de un tipo?
- 8. Usando partes de GUID como ID
- 9. ¿Por qué usar tuplas en lugar de objetos?
- 10. ¿Por qué $ ('# id') devuelve verdadero si el id no existe?
- 11. isEqual no siempre funciona para NSIndexPath? ¿Qué puedo usar en su lugar?
- 12. por qué usar - en lugar de _ en la url
- 13. Qué tipos de enteros usar para enteros de datos centrales
- 14. ¿Es siempre mejor usar 'DbContext' en lugar de 'ObjectContext'?
- 15. ¿Qué puedo usar en lugar de eval()?
- 16. ¿Por qué usar C typedefs en lugar de #defines?
- 17. ¿Por qué no debo usar siempre tipos que aceptan valores de nulo en C#
- 18. ¿Por qué debería usar git en lugar de svn?
- 19. ¿Por qué usar char [] en lugar de String?
- 20. ¿Por qué usar string :: iterator en lugar de index?
- 21. ¿por qué no subprocesamos.Popen (...) siempre regresa?
- 22. ¿Por qué debería usar url.openStream en lugar de url.getContent?
- 23. ¿Por qué usar select() en lugar de sleep()?
- 24. ¿Por qué usar curl en lugar de otros métodos?
- 25. ¿Por qué usar registerDefaults: en lugar de setValue: forKey :?
- 26. ¿Por qué usar AsQueryable() en lugar de List()?
- 27. ¿por qué debería usar content_tag en lugar de html "normal"?
- 28. Servidor SQL: ¿por qué el 15º carácter de un GUID siempre es 4?
- 29. ¿Por qué usar GWT.create() en lugar de nuevo?
- 30. Por qué/cuándo usar (!! p) en lugar de (p! = NULO)
@Jonathan: Bueno, se necesitan 5, ¿eh? – Eric
¿De qué estás hablando? – Mitch
Su pregunta ha sido votada para que la cierre alguien de la comunidad. No te preocupes, se necesitan 5 personas para votar una pregunta cerrada. –