No estoy muy familiarizado con las bases de datos y las teorías detrás de cómo funcionan. ¿Es más lento desde el punto de vista del rendimiento (insertar / actualizar / consultar) usar cadenas para claves primarias que enteros?
No estoy muy familiarizado con las bases de datos y las teorías detrás de cómo funcionan. ¿Es más lento desde el punto de vista del rendimiento (insertar / actualizar / consultar) usar cadenas para claves primarias que enteros?
Respuestas:
Técnicamente sí, pero si una cadena tiene sentido para ser la clave principal, entonces probablemente debería usarla. Todo esto depende del tamaño de la tabla para la que está haciendo y de la longitud de la cadena que será la clave principal (cadenas más largas == más difíciles de comparar). No necesariamente usaría una cadena para una tabla que tiene millones de filas, pero la cantidad de desaceleración de rendimiento que obtendrá al usar una cadena en tablas más pequeñas será minúscula para los dolores de cabeza que puede tener al tener un número entero que no No significa nada en relación con los datos.
Otro problema con el uso de cadenas como clave principal es que debido a que el índice se coloca constantemente en orden secuencial, cuando se crea una nueva clave que estaría en el medio del orden, el índice debe volver a secuenciarse ... si usa un auto número entero, la nueva clave se acaba de agregar al final del índice.
Las inserciones en una tabla que tiene un índice agrupado donde la inserción ocurre en el medio de la secuencia NO hace que el índice se reescriba. No hace que las páginas que comprenden los datos se reescriban. Si hay espacio en la página donde irá la fila, entonces se coloca en esa página. La página individual se reformateará para colocar la fila en el lugar correcto de la página. Cuando la página está llena, ocurrirá una división de página, con la mitad de las filas de la página yendo a una página y la otra mitad yendo a la otra. Las páginas se vuelven a vincular en la lista vinculada de páginas que comprenden una tabla de datos que tiene el índice agrupado. Como máximo, terminarás escribiendo 2 páginas de base de datos.
Las cadenas son más lentas en las uniones y en la vida real rara vez son realmente únicas (incluso cuando se supone que deben ser). La única ventaja es que pueden reducir el número de uniones si se une a la tabla primaria solo para obtener el nombre. Sin embargo, las cadenas también están sujetas a cambios, lo que crea el problema de tener que arreglar todos los registros relacionados cuando cambia el nombre de la empresa o la persona se casa. Esto puede ser un gran impacto en el rendimiento y si todas las tablas que deberían estar relacionadas de alguna manera no están relacionadas (esto sucede con más frecuencia de lo que piensa), entonces también podría tener desajustes de datos. Un número entero que nunca cambiará durante la vida útil del registro es una opción mucho más segura desde el punto de vista de la integridad de los datos, así como desde el punto de vista del rendimiento. Las claves naturales generalmente no son tan buenas para el mantenimiento de los datos.
También quiero señalar que lo mejor de ambos mundos es a menudo usar una clave de autoincremento (o en algunos casos especializados, un GUID) como PK y luego poner un índice único en la clave natural. Obtiene las uniones más rápidas, no obtiene registros duplicados y no tiene que actualizar un millón de registros secundarios porque cambió el nombre de una empresa.
No importa lo que use como clave principal siempre que sea ÚNICO. Si le importa la velocidad o el buen diseño de la base de datos, use int a menos que planee replicar datos, luego use un GUID.
Si se trata de una base de datos de acceso o una pequeña aplicación, ¿a quién le importa realmente? Creo que la razón por la cual la mayoría de nosotros los desarrolladores damos una palmada al viejo int o guid en el frente es porque los proyectos tienen una forma de crecer en nosotros, y usted quiere dejarse la opción de crecer.
Demasiadas variables Depende del tamaño de la tabla, los índices, la naturaleza del dominio de clave de cadena ...
En general , los enteros serán más rápidos. ¿Pero será la diferencia lo suficientemente grande como para preocuparse? Es difícil de decir.
Además, ¿cuál es su motivación para elegir cuerdas? Las teclas numéricas de incremento automático a menudo también son mucho más fáciles . ¿Es semántica? ¿Conveniencia? Replicación / preocupaciones desconectadas? Su respuesta aquí podría limitar sus opciones. Esto también le recuerda una tercera opción "híbrida" que está olvidando: las guías.
No se preocupe por el rendimiento hasta que tenga un diseño simple y sólido que esté de acuerdo con el tema que los datos describen y se ajusta bien con el uso previsto de los datos. Luego, si surgen problemas de rendimiento, puede resolverlos ajustando el sistema.
En este caso, casi siempre es mejor usar una cadena como clave primaria natural, siempre que pueda confiar en ella. No se preocupe si es una cadena, siempre que la cadena sea razonablemente corta, digamos unos 25 caracteres como máximo. No pagará un gran precio en términos de rendimiento.
¿Las personas de entrada de datos o las fuentes de datos automáticas siempre proporcionan un valor para la supuesta clave natural, o a veces se omite? ¿Ocasionalmente está mal en los datos de entrada? Si es así, ¿cómo se detectan y corrigen los errores?
¿Los programadores y los usuarios interactivos que especifican consultas pueden usar la clave natural para obtener lo que desean?
Si no puede confiar en la clave natural, invente un sustituto. Si inventa un sustituto, también podría inventar un número entero. Luego debe preocuparse por si ocultar el sustituto de la comunidad de usuarios. Algunos desarrolladores que no ocultaron la clave sustituta llegaron a lamentarlo.
Los índices implican muchas comparaciones.
Por lo general, las cadenas son más largas que los enteros y las reglas de intercalación pueden aplicarse para la comparación, por lo que comparar cadenas suele ser una tarea computacionalmente más intensa que comparar números enteros.
A veces, sin embargo, es más rápido usar una cadena como clave principal que hacer una unión adicional con una string to numerical idtabla.
Sí, pero a menos que espere tener millones de filas, no usar una clave basada en cadenas porque es más lenta suele ser "optimización prematura". Después de todo, las cadenas se almacenan como números grandes, mientras que las teclas numéricas generalmente se almacenan como números más pequeños.
Sin embargo, una cosa a tener en cuenta es si tiene índices agrupados en cualquier tecla y está haciendo un gran número de inserciones que no son secuenciales en el índice. Cada línea escrita hará que el índice se vuelva a escribir. Si está haciendo inserciones por lotes, esto realmente puede ralentizar el proceso.
Dos razones para usar enteros para columnas PK:
Podemos establecer la identidad para el campo entero que se incrementó automáticamente.
Cuando creamos PK, la base de datos crea un índice (Cluster o Non Cluster) que clasifica los datos antes de almacenarlos en la tabla. Al usar una identidad en una PK, el optimizador no necesita verificar el orden antes de guardar un registro. Esto mejora el rendimiento en mesas grandes.
¿Cuál es su razón para tener una cadena como clave principal?
Simplemente establecería la clave primaria en un campo entero de incremento automático y pondría un índice en el campo de cadena.
De esa manera, si realiza búsquedas en la tabla, deberían ser relativamente rápidas, y todas sus uniones y búsquedas normales no se verán afectadas en su velocidad.
También puede controlar la cantidad del campo de cadena que se indexa. En otras palabras, puede decir "solo indexe los primeros 5 caracteres" si cree que será suficiente. O si sus datos pueden ser relativamente similares, puede indexar todo el campo.
Desde el punto de vista del rendimiento: Sí, la cadena (PK) ralentizará el rendimiento en comparación con el rendimiento logrado utilizando un número entero (PK), donde PK ---> Clave primaria.
Desde el punto de vista de los requisitos: aunque esto no es parte de su pregunta, me gustaría mencionarlo. Cuando manejamos grandes cantidades de datos en diferentes tablas, generalmente buscamos el conjunto probable de claves que se pueden establecer para una tabla en particular. Esto se debe principalmente a que hay muchas tablas y, en su mayoría, cada una de ellas estaría relacionada entre sí a través de alguna relación (un concepto de clave externa). Por lo tanto, no siempre podemos elegir un número entero como Clave primaria, sino que elegimos una combinación de 3, 4 o 5 atributos como clave primaria para esas tablas. Y esas claves pueden usarse como una clave externa cuando relacionaríamos los registros con alguna otra tabla. Esto hace que sea útil relacionar los registros en diferentes tablas cuando sea necesario.
Por lo tanto, para un uso óptimo: siempre hacemos una combinación de 1 o 2 enteros con 1 o 2 atributos de cadena, pero nuevamente solo si es necesario.
Podría haber un gran malentendido relacionado con la cadena en la base de datos. Casi todos han pensado que la representación de números en la base de datos es más compacta que las cadenas. Piensan que en db-s los números se representan como en la memoria. Pero no es cierto. En la mayoría de los casos, la representación numérica está más cerca de una cadena como la representación como otra.
La velocidad de usar número o cadena depende más de la indexación que del tipo en sí.
Por defecto, ASPNetUserIds son 128 cadenas de caracteres y el rendimiento está bien.
Si la clave TIENE que ser única en la tabla, debería ser la Clave. Este es el por qué;
clave de cadena primaria = relaciones correctas de base de datos, 1 clave de cadena (la primaria) y 1 índice de cadena (la primaria).
La otra opción es una Clave int típica, pero si la cadena TIENE que ser única, probablemente necesitará agregar un índice debido a consultas continuas para validar o verificar que es única.
Entonces, usar una clave de identidad int = Relaciones de base de datos incorrectas, 1 clave int (Primaria), 1 índice int (Primaria), Probablemente una cadena única Índice, y tener que validar manualmente la misma cadena no existe (algo así como una comprobación de sql )
Para obtener un mejor rendimiento usando un int sobre una cadena para la clave primaria, cuando la cadena TIENE que ser única, tendría que ser una situación muy extraña. Siempre he preferido usar teclas de cadena. Y como buena regla general, no desnormalice una base de datos hasta que NECESITA .