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) utilizar cadenas para claves primarias que enteros?Cadenas como claves principales en la base de datos SQL
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 va a ser la clave principal (cadenas más largas == más difíciles de comparar). No usaría necesariamente 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úsculo para los dolores de cabeza que puede tener al tener un número entero que no lo hace no significa nada en relación con los datos.
Los índices implican muchas comparaciones.
Normalmente, las cadenas son más largas que los enteros y las reglas de intercalación se pueden aplicar para la comparación, por lo que la comparación de cadenas suele ser una tarea más intensiva computacionalmente que la comparación de enteros.
A veces, sin embargo, es más rápido usar una cadena como clave principal que hacer una unión extra con una tabla string to numerical id.
Demasiadas variables. Depende del tamaño de la tabla, los índices, la naturaleza del dominio de la clave de cadena ...
Generalmente, los enteros serán más rápidos. ¿Pero la diferencia será lo suficientemente grande como para importarle? Es difícil de decir.
Además, ¿cuál es su motivación para elegir cadenas? Las claves numéricas de autoincremento a menudo son tan más fáciles también. ¿Es semántica? ¿Conveniencia? ¿Replicación/inquietudes desconectadas? Su respuesta aquí podría limitar sus opciones. Esto también trae a la mente una tercera opción "híbrida" que te olvidas: Guías.
Cadenas para la coherencia entre muchas bases de datos – systemoutprintln
que no tiene sentido cloutierm, ¿qué quieres decir? – HLGEM
@HLGEM: si lo entiendo escribir, quiere decir sincronizar registros creados en una computadora portátil con la base de datos principal. –
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 resecuenciarse ... si utiliza un número entero automático, la nueva clave se acaba de agregar al final del índice.
Sin embargo, esto puede causar "puntos calientes" para nuevas inserciones. Siempre que administre su base de datos correctamente, debería tener espacio adicional en sus páginas para inserciones de todos modos y las divisiones de página deberían ser excepcionales. –
que es cuando las claves primarias se agrupan. puedes crearlos también no agrupados. – Learning
Sí, pero a menos que espere tener millones de filas, no usar una clave basada en cadenas porque es más lento suele ser una "optimización prematura". Después de todo, las cadenas se almacenan como números grandes, mientras que las claves 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 una tecla cualquiera y está haciendo un gran número de insertos que no son secuenciales en el índice. Cada línea escrita causará que el índice vuelva a escribir. si está haciendo inserciones por lotes, esto realmente puede ralentizar el proceso.
¿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é un índice en el campo de cadena.
De esta forma, si realiza búsquedas en la tabla, éstas deberían ser relativamente rápidas, y todas sus combinaciones 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.
Creo que poner inteligencia en una llave es buscar problemas. ¿Serán únicos? Comenzaron todos los números de cuenta con la abreviatura del estado al principio solo para la mudanza del cliente. Actualice un campo - no hay problema - todas esas tablas vinculadas por número de cuenta - qué desastre. – JeffO
Un ejemplo de uso de una cadena como PK podría ser una tabla de configuraciones. p.ej. settingNamePK, isUserEditable, isCustomerEditable etc Luego, si desea modificar el comportamiento de configuración "ACTUALIZAR configuración SET ... DONDE settingNamePK = 'dailyWorkObligation'" es mucho mejor que tener que usar ID's y almacenar en algún lugar la asignación de los identificadores. Por supuesto, podría tener un entero PK y tener el nombre de la configuración como otra clave única también. – MeatPopsicle
Con la clave primaria como un entero autoincrementado, ¿las inserciones tampoco deberían verse afectadas en su velocidad? – Dennis
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 esta es una base de datos de acceso o una aplicación pequeña, ¿a quién le importa realmente? Creo que la razón por la cual la mayoría de los desarrolladores de nosotros damos una palmada a la vieja int o guid en el frente es porque los proyectos tienen una forma de crecer sobre nosotros, y queremos dejarnos la opción de crecer.
Las cadenas son más lentas en las uniones y en la vida real rara vez son realmente únicas (incluso cuando se supone que lo son). La única ventaja es que pueden reducir el número de combinaciones si se está uniendo a la tabla principal solo para obtener el nombre. Sin embargo, las cadenas también suelen estar sujetas a cambios, lo que crea el problema de tener que corregir todos los registros relacionados cuando el nombre de la empresa cambia o la persona se casa. Esto puede ser un gran golpe de rendimiento y si todas las tablas que deberían estar relacionadas de alguna manera no están relacionadas (esto sucede más a menudo de lo que piensas), entonces también podrías tener desajustes de datos. Un número entero que nunca cambiará a lo largo de la vida del registro es una opción mucho más segura desde el punto de vista de la integridad de los datos y 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 suele ser utilizar una clave de autoincrementing (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.
Las cadenas que son buenas candidatas para PK no tienen duplicados; de lo contrario, no serían un buen candidato para PK. Piense en códigos ICD-9, códigos de país, números VIN. Usar un nombre como ejemplo de un problema con las claves naturales está mal orientado, porque nunca deberían ser candidatos en primer lugar. –
@Tom H: Los códigos ISO del condado SI cambian. [http://en.wikipedia.org/wiki/ISO_3166-1#Editions_and_changes] Como respuesta a una pregunta relacionada dijo [http://stackoverflow.com/questions/925266/database-design-and-the-use- of-non-numeric-primary-keys/925290 # 925290] "Para PRIMARY KEY, asegúrese de que su exclusividad esté bajo su control" –
@SteveSchnepp: sí, y el ISO es el organismo de confianza para gestionar ese cambio. Por otro lado, cuando necesitas fusionar tu secuencia monotónica de incrementar valores enteros con los de otra persona, estás solo;) – onedaywhen
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 las bases de datos es más compacta que en cadenas. Ellos 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 que de otra.
La velocidad de uso del número o cadena depende más de la indexación que del tipo en sí.
Desde el punto de vista del rendimiento: la cadena Sí (PK) ralentizará el rendimiento en comparación con el rendimiento obtenido con un número entero (PK), donde PK ---> Clave principal.
Desde el punto de vista de los requisitos: aunque esto no forma parte de su pregunta, me gustaría mencionarlo. Cuando manejamos datos enormes 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 o alguna tabla se relacionaría con la otra a través de alguna relación (un concepto de clave externa). Por lo tanto, realmente no siempre podemos elegir un número entero como clave principal, sino que buscamos una combinación de 3, 4 o 5 atributos como la clave principal para esas tablas. Y esas claves se pueden utilizar 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 de nuevo solo si es necesario.
No se preocupe por el rendimiento hasta que obtenga un diseño simple y sólido que coincida con el tema que describen los datos y que se ajuste bien al uso previsto de los datos. Luego, si surgen problemas de rendimiento, puede solucionarlos ajustando el sistema.
En este caso, casi siempre es mejor utilizar una cadena como clave primaria natural, siempre que pueda confiar en ella. No se preocupe si se trata de 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 que ingresan datos o las fuentes de datos automáticas siempre proporcionan un valor para la supuesta clave natural, o a veces se omite? ¿Es ocasionalmente incorrecto en los datos de entrada? Si es así, ¿cómo se detectan y se corrigen los errores?
¿Los programadores y usuarios interactivos que especifican consultas pueden usar la clave natural para obtener lo que quieren?
Si no puede confiar en la clave natural, invente un sustituto. Si inventa un sustituto, también podría inventar un número entero. Entonces debe preocuparse por ocultar el sustituto de la comunidad de usuarios. Algunos desarrolladores que no ocultaron la clave sustituta llegaron a arrepentirse.
Inserta en una tabla que tiene un índice agrupado en el que la inserción ocurre en el medio de la secuencia NO hace que se reescriba el índice. No causa la reescritura de las páginas que componen los datos. 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, se producirá una división de página, con la mitad de las filas en la página yendo a una página y la mitad yendo en la otra. Las páginas se vuelven a vincular en la lista de páginas vinculadas que comprende una tabla de datos que tiene el índice agrupado. Como máximo, terminará escribiendo 2 páginas de base de datos.
Buena explicación. Pero ¿esto es cierto para todas las bases de datos SQL? He oído hablar de problemas de rendimiento de MySQL al usar UUID aleatorio como clave principal. – hgoebl
Dos razones para usar números enteros para las columnas de PK:
podemos establecer la identidad para el campo entero que incrementa automáticamente.
Cuando creamos PK, el db crea un índice (Cluster or Non Cluster) que ordena los datos antes de que se almacenen en la tabla. Al usar una identidad en un PK, el optimizador no necesita verificar el orden de clasificación antes de guardar un registro. Esto mejora el rendimiento en tablas grandes.
Por defecto ASPNetUserIds son 128 cadenas de caracteres y el rendimiento está muy bien.
Si la clave tiene para ser única en la tabla, debe ser la clave. Este es el por qué;
clave de cadena primaria = Corregir relaciones de base de datos, 1 clave de cadena (La primaria) y 1 cadena Índice (La primaria).
La otra opción es un típico int clave, pero si la cadena TIENE que ser único que todavía probablemente tendrá que añadir un índice debido a non-stop consultas para validar o verificar que su único.
Utilizando una clave de identidad int = relaciones de base de datos incorrectas, 1 clave int (primaria), 1 índice int (principal), probablemente un índice de cadena única, y tener que validar manualmente la misma cadena no existe (algo como un cheque sql tal vez).
Para obtener un mejor rendimiento utilizando un int más de una cadena para la clave principal, cuando la cadena TIENE que ser único, que tendría que ser una situación muy extraña. Siempre he preferido usar claves de cadena. Y como regla general, no desnormalice una base de datos hasta que NECESITA a.
¿no dependería de la base de datos? ¿Pensaría que una cadena correctamente indexada no sería mucho más lenta si se tratara de un número? –
Estoy de acuerdo en que hay muchas variables a considerar. (En sqlserver) hemos visto problemas reales de rendimiento con el uso de cadenas con longitudes entre los adolescentes de mediana a alta y superiores, incluso cuando están indexadas. Compre que tiene razón para superar este hardware, por ejemplo. – kemiller2002
Bastante justo. Sin embargo, estaría de acuerdo en que si una cuerda tiene sentido, eso es lo que deberías usar. También diría que definitivamente hay momentos para los campos GUID o UUID en las bases de datos donde un campo de autoincrementación no funcionaría. –