No estoy muy familiarizado con bases de datos y las teorías detrás de cómo funcionan. Es más lento desde un punto de vista del rendimiento (insertar/actualizar/consultar) para el uso de Cadenas para las Claves Primarias de los números enteros?

14 Comentarios

  1. 166

    Técnicamente sí, pero si una cadena tiene sentido ser la clave principal, entonces usted probablemente debería utilizar. Todo esto depende del tamaño de la tabla que vamos a hacer y la longitud de la cadena que va a ser la clave principal (o más cadenas == más difíciles de comparar). Yo no necesariamente el uso de una cadena para una tabla que cuenta con millones de filas, pero la cantidad de disminución de rendimiento que va a obtener mediante el uso de una cuerda en tablas más pequeñas serán las minúsculas para los dolores de cabeza que usted puede tener por tener un número entero que no significa nada en relación a los datos.

    • no dependen de la base de datos? Yo creo que un indexe correctamente en la cadena no sería mucho más lento si en absoluto de un número?
    • Yo estaría de acuerdo en que hay una gran cantidad de variables a considerar. (En sqlserver) hemos visto la realidad de los problemas de rendimiento con el uso de las cadenas con las longitudes, en la segunda mitad de adolescentes de alto y por encima incluso cuando indexado. Comprar tienes razón, hay cosas para superar este tipo de hardware, por ejemplo.
    • Justo lo suficiente. Yo estaría de acuerdo en que a pesar de que si una cadena tiene sentido, que es lo que debes usar. También quiero decir que definitivamente, hay momentos para GUID o UUID campos en las bases de datos en un campo autoincrement no iba a funcionar.
    • También hay que tener en cuenta que a menudo hay una diferencia muy grande entre un CHAR y VARCHAR cuando haciendo índice de comparaciones
    • El número de comentarios de esta respuesta pone de manifiesto incompleto. Mencionar la indexación de lo que habría sido el mínimo aceptable respuesta.
  2. 65

    Otro problema con el uso de las Cuerdas, como una clave principal es que, dado que el índice es constantemente puesto en orden secuencial, cuando se crea una nueva clave de que estaría en el medio de la orden y el índice tiene que ser secuenciados de nuevo… si uso el auto de un número entero, la nueva clave se acaba de agregar a la final del índice.

    • Esto puede causar que los «puntos calientes» para los nuevos insertos de aunque. Mientras estés en la gestión de su base de datos correctamente, usted debe de tener más espacio en sus páginas para las inserciones de todos modos y las divisiones de página deben ser raras.
    • que es cuando las claves principales se agrupan. puede crear desagrupado demasiado.
  3. 19

    Inserta en una tabla que tiene un índice agrupado en donde la inserción se produce en medio de la secuencia NO causa el índice de volver a escribir. No causa las páginas que componen los datos a ser reescrito. Si hay espacio en la página donde la fila se van, luego se coloca en la página. La única página que se formateará a cabo la fila en el lugar correcto en la página. Cuando la página está llena, una división de página que va a suceder, con la mitad de las filas de la página que se va a una página, y la mitad se va en el otro. Las páginas se vuelven a vincular en la lista enlazada de las páginas que componen una de las tablas de datos que tiene el índice agrupado. En la mayoría, van a terminar de escribir 2 páginas de base de datos.

    • Buena explicación. Pero es esto cierto para todas las bases de datos de SQL? He oído hablar de MySQL problemas de rendimiento cuando se utiliza al azar UUID como clave primaria.
  4. 12

    Cadenas son más lentos en las uniones y en la vida real son muy rara vez realmente único (incluso cuando se supone que ellos son). La única ventaja es que se puede reducir el número de combinaciones si usted se une a la tabla principal sólo para obtener el nombre. Sin embargo, las cadenas de caracteres también se encuentran sujetas a cambio creando así el problema de tener que solucionar todos los registros relacionados cuando la empresa los cambios de nombre o de la persona que se casa. Esto puede ser un enorme impacto en el rendimiento y si todas las tablas deben estar relacionadas de alguna manera no están relacionados (esto sucede más a menudo de lo que piensas), entonces usted puede haber discrepancias de datos así. Un entero que nunca va a cambiar a través de la vida de el registro es una opción más segura desde un punto de vista de la integridad de los datos así como desde un punto de vista del rendimiento. Claves naturales generalmente no son tan buenos para el mantenimiento de los datos.

    También quiero señalar que lo mejor de ambos mundos es a menudo el uso de un autoincrementing clave (o en algunos especializados de los casos, un GUID) como el PK y, a continuación, poner en un índice único en la clave natural. Obtener el más rápido une, no;t obtener registros duplicados, y usted no tiene que actualizar un millón de registros de el niño debido a que una empresa cambió de nombre.

    • Las cadenas que son buenos candidatos para PKs no tiene duplicados – de lo contrario no sería una buena candidata para un PK. Creo que de la CIE-9 códigos, los códigos de país, VIN #s. El uso de un nombre como un ejemplo de un problema con las claves naturales es equivocada, porque ellos nunca deben ser candidato en el primer lugar.
    • H: ISO Condado de códigos de HACER el cambio. [ en.wikipedia.org/wiki/ISO_3166-1#Editions_and_changes ] Como una respuesta a una pregunta relacionada dijo [ stackoverflow.com/questions/925266/… ] «Para la CLAVE PRINCIPAL es asegurarse de que su singularidad es bajo tu control»
    • sí, y si el ISO es la confianza del cuerpo para la gestión de ese cambio. Por otro lado, cuando se necesita combinar su monótona secuencia de incremento de los valores enteros con el de alguien más, usted está en su propia 😉
    • Yo estaría de acuerdo en que los nombres si acaso no será considerada como una clave , acabo de ver a omany veces cuando se fueron.
    • la fusión de 2 monótona secuencia de incremento de número entero es bastante fácil de hacer a través de un prefijo o suffixing 🙂
    • Buena respuesta! Usted puede pensar que el uso de cadenas en la IDENTIFICACIÓN de añadir un prefijo, pero como usted dijo, ¿y si el prefijo de cambios. En lugar de almacenar el prefijo en un campo independiente y concatenar en la identificación cuando se muestra.

  5. 6

    No importa lo que se utiliza como una clave principal en la medida que es ÚNICO. Si usted se preocupa acerca de la velocidad o el buen diseño de base de datos uso de la int a menos que usted planea en la replicación de los datos, a continuación, utilizar un GUID.

    Si se trata de una base de datos de access o algún pequeño de la aplicación, a continuación, que realmente se preocupa. Creo que la razón por la que la mayoría de nosotros, los desarrolladores de la palmada de la antigua int o guid en la parte delantera es debido a que los proyectos tienen un modo de crecer en nosotros, y deje la opción de crecer.

  6. 4

    Demasiadas variables. Depende del tamaño de la tabla, los índices, la naturaleza de la cadena de clave de dominio…

    Generalmente, enteros será más rápido. Pero la diferencia de ser lo suficientemente grande como para atención? Es difícil de decir.

    También, ¿cuál es su motivación para la elección de las cadenas? Numérico de incremento automático de teclas son a menudo mucho más fácil así. Es la semántica? Conveniencia? Replicación/desconectado preocupaciones? Aquí la respuesta que podría limitar sus opciones. Esto también trae a la mente una tercera «híbrido» de la opción que estás olvidando de: Guid.

    • Cadenas para la coherencia entre las muchas bases de datos
    • que no tiene ningún sentido cloutierm, ¿a qué te refieres?
    • Si yo entiendo que él escriba, que él entiende como la sincronización de los registros creados en un ordenador portátil con el principal db.
    • Quiero decir que tengo dos bases de datos independientes con las mismas entidades, sólo uno se actualiza con menos frecuencia para el almacenamiento persistente de los propósitos. Si me Consulta para la entidad «California» en Una Base de datos, quiero que sea fundamentalmente el mismo que el «California» en la Base de datos B.
    • que la replicación.
    • Y es que ‘me gusta’ a la sincronización de los registros creados en un ordenador portátil que es el mismo problema: los registros creados en un lugar no deben entrar en conflicto con los registros creados en otro. Una posible solución a este problema es el Guid de teclas.

  7. 4

    No te preocupes por el rendimiento, hasta que usted tiene una simple y el diseño de sonido que está de acuerdo con el tema que los datos se describe y encaja muy bien con el uso previsto de los datos. Entonces, si el rendimiento de la aparición de los problemas, se puede tratar con ellos por medio de modificaciones en el sistema.

    En este caso, casi siempre es mejor ir con una cadena natural de la clave principal, proporcionar usted puede confiar en ella. No te preocupes si es una cadena, siempre y cuando la cadena es razonablemente corto, digamos unos 25 caracteres como máximo. Usted no va a pagar un alto precio en términos de rendimiento.

    Hacer la entrada de datos de las personas o automática de las fuentes de datos siempre proporcionar un valor para el supuesto natural de la tecla, o a veces es omitido? Es a veces mal en los datos de entrada? Si es así, ¿cómo son los errores detectados y corregidos?

    Son los programadores y los usuarios interactivos que especificar consultas capaz de utilizar la clave natural para conseguir lo que quieren?

    Si usted no puede confiar en la clave natural, inventar un sustituto. Si usted inventar un sustituto, usted podría inventar un entero. Entonces usted tiene que preocuparse acerca de whther para ocultar el sustituto de la comunidad de usuarios. Algunos desarrolladores que no esconder la clave suplente llegó a arrepentir.

  8. 2

    Sí, pero a menos que usted espera tener millones de filas, no mediante una cadena de claves basados porque es más lento normalmente es «prematuro optimización.» Después de todo, las cadenas se almacenan como números grandes, mientras que las teclas numéricas son generalmente almacenados como números más pequeños.

    Una cosa a tener en cuenta, sin embargo, es si han agrupado los índices en un cualquier tecla y están haciendo un gran número de inserciones que no son secuenciales en el índice. Cada línea escrita hará que el índice de re-escribir. si usted está haciendo lote inserta, esto realmente puede ralentizar el proceso.

  9. 2

    Índices implica un montón de comparaciones.

    Normalmente, las cadenas son más largos que los enteros y las reglas de intercalación puede ser aplicado para la comparación, por lo que la comparación de cadenas es generalmente más intensas tareas de comparación de números enteros.

    A veces, sin embargo, es más rápido usar una cadena como una clave principal que para hacer un extra de unirse con un string to numerical id tabla.

  10. 2

    Dos razones para el uso de números enteros para PK columnas:

    1. Podemos establecer la identidad de campo entero que se incrementa automáticamente.

    2. Cuando creamos PKs, la base de datos se crea un índice (Clúster o No Clúster) que ordena los datos antes de que se almacenan en la tabla. Mediante el uso de una identidad en un PK, el optimizador no necesita comprobar el orden de clasificación antes de guardar un registro. Esto mejora el rendimiento en tablas grandes.

  11. 1

    ¿Cuál es tu razón para tener una cadena como una clave principal?

    Me acaba de establecer la clave principal para un auto incremento campo entero, y poner un índice en el campo de cadena de caracteres.

    De esa manera si usted hace búsquedas en la tabla deben ser relativamente rápido, y todas sus combinaciones y de aspecto normal ups serán afectadas en su velocidad.

    También puede controlar la cantidad de la cadena de campo que se indica. En otras palabras, se puede decir «sólo el índice de los primeros 5 caracteres» si crees que va a ser suficiente. O si sus datos pueden ser relativamente similares, usted puede indexar todo el campo.

    • Creo que poner la inteligencia en una clave es buscar problemas. Estarán único? Hizo empiezan todos los números de cuenta con el estado de la abreviatura en el inicio, sólo para que el cliente se mueva. La actualización de un campo – no hay problema – todas las tablas vinculadas por número de cuenta – ¡qué lío.
    • Un ejemplo del uso de una cadena como un PK podría ser una tabla de valores. por ejemplo, settingNamePK, isUserEditable, isCustomerEditable etc, si se quería modificar la configuración de la conducta «ACTUALIZACIÓN de la configuración de la … DONDE settingNamePK=’dailyWorkObligation'» es mucho mejor que tener que usar una ID y almacenar en algún lugar de la asignación de los ID. Por supuesto, usted puede tener un número entero PK y tiene el nombre de la opción como otra clave única así.
    • Con la clave principal de ser un auto-incrementa entero, no inserta también se verá afectada en su velocidad?
    • Para los curiosos Rieles devs, aquí está cómo especificar un índice de longitud. Tenga en cuenta que SQLite no índice de apoyo a la longitud.
  12. 1

    Desde el punto de vista del rendimiento – Sí string(PK) se ralentizará el rendimiento cuando se compara con el rendimiento alcanzado usando un entero(PK), donde PK —> Clave Principal.

    De requisito punto de vista – Aunque esto no es una parte de la cuestión que me gustaría mencionar. Cuando estamos en el manejo de gran cantidad de datos a través de diferentes tablas, en general, para la posibilidad de que un conjunto de teclas que se pueden establecer para una tabla determinada. Esto es principalmente porque hay muchas mesas y sobre todo cada uno o de la tabla, estaría relacionado con el otro a través de la relación ( un concepto de Clave externa ). Por lo tanto, que realmente no siempre se puede elegir un número entero como una Clave Principal, en lugar de ir por una combinación de 3, 4 o 5 atributos como la clave principal para que las tablas. Y esas claves puede ser utilizado como una clave externa a la hora de relacionar los registros con algunos otros de la tabla. Esto lo hace útil para relacionar los registros a través de 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 la cadena, pero de nuevo sólo si es necesario.

  13. 0

    Podría ser un gran malentendido relacionados con la cadena en la base de datos. Casi todo el mundo ha pensado que la base de datos de la representación de los números son más compactos que los de cadenas. Ellos piensan que en el db-s se representan los números como en la memoria. PERO no es cierto. En la mayoría de los casos la representación de números está más cerca de Una cadena, como representación, como a las otras.

    La velocidad de la utilización de número o una cadena es más dependiente de la indización, a continuación, el propio tipo.

  14. 0

    Por defecto ASPNetUserIds son de 128 char cadenas y el rendimiento está bien.

    Si la clave HA a ser único en la tabla debe ser la Clave. He aquí por qué;

    primaria string clave = Correcto DB relaciones, 1 clave de la cadena(El principal), y 1 cadena de Índice(El Primario).

    La otra opción es un típico int Clave, pero si la cadena HA a ser único probablemente usted todavía necesita para añadir un índice porque de no dejar de consultas para validar o comprobar que su único.

    Lo que usar un int identidad clave = Incorrecto DB Relaciones, 1 int clave Primaria(primary), 1 int index(Primaria), Probablemente una cadena única, y el Índice manual de validar la misma cadena no existe(algo así como una comprobación de sql tal vez).

    Para obtener un mejor rendimiento usando un int a través de una cadena de la clave primaria, cuando la cadena HA a ser único, tendría que ser una situación muy extraña. Siempre he preferido el uso de claves de cadena. Y como una buena regla de oro, no denormalize una base de datos hasta que NECESIDAD a.

Dejar respuesta

Please enter your comment!
Please enter your name here