¿Realmente es tan malo usar "varchar" como la clave principal?¿Utiliza "varchar" como clave principal? ¿mala idea? o bien?
(será el almacenamiento de documentos del usuario, y sí que puede exceder de + 2 mil millones de documentos)
Depende totalmente de los datos. Hay muchos casos perfectamente legítimos en los que podría usar una clave principal VARCHAR, pero si existe la posibilidad más remota de que alguien quiera actualizar la columna en cuestión en algún momento en el futuro, no la use como clave.
re la actualización ¿por qué? – Mark
@Mark - Las claves principales deben ser estables. Si los actualiza puede ser necesario que los cambios se propaguen a otras tablas usándolos como FK, también de forma predeterminada se convierten en la clave de clúster en SQL Server, por lo que se duplican para actuar también como el localizador de filas en índices no agrupados, que también necesitarían estar actualizado. –
para que se aplique a cualquier tipo no solo a varchar – Mark
utilizar un ID (esto se convertirá en útil si desea mostrar sólo el 50 etc ...). Luego establezca una restricción ÚNICA en su varchar con los nombres de archivo (supongo, eso es lo que está almacenando).
Esto hará el truco y aumentará la velocidad.
Explique cómo agregar un 'id' será útil para mostrar solo 50. Estas no se garantizan de forma secuencial y revierte y elimina los huecos. Además, al establecer una restricción única en la columna, esto la convierte en una clave candidata, en cuyo caso es arbitraria cuál seleccione como clave principal. Si tiene varias claves candidatas impuestas por cualquier tipo de índice único, cualquiera de ellas puede participar en relaciones de claves externas. –
Cuando va a mostrar estos nombres de archivos, realmente no desea seleccionar 2 mil millones de registros y que limitan 50. Con una ID, puede seleccionar todos los archivos donde ID> some_position_you_saved. Esto mejorará la velocidad de ejecución por ... bueno ... mucho :-). – JNDPNT
Usted puede hacer eso con 'varchar' también. Seguirá buscando en el lugar correcto en el índice y luego recuperará las filas 'TOP 50' desde ese punto. –
Creo que int o bigint a menudo es mejor.
Si va a unirse a otras tablas, un varchar, particularmente un varchar ancho, puede ser más lento que un int.
Además, si tiene muchos registros secundarios y el varchar es algo sujeto a cambios, las actualizaciones en cascada pueden causar bloqueos y retrasos para todos los usuarios. Un varchar como el número de VIN de un coche que rara vez cambiará será bueno. Un varchar como un nombre que cambiará puede ser una pesadilla esperando a suceder. PKs debe ser estable si es posible.
Siguiente muchas posibles varchar Pks no son realmente únicas y, a veces, parecen ser únicas (como números de teléfono) pero se pueden reutilizar (renuncias al número, la compañía telefónica lo reasigna) y luego se pueden adjuntar registros secundarios el lugar equivocado Así que asegúrese de tener un valor inmutable único antes de usar.
Si decide utilizar una clave sustituta, cree un índice único para el campo varchar. Esto le brinda los beneficios de las uniones más rápidas y menos registros para actualizar si algo cambia pero mantiene el uniquess que desea.
Ahora, si no tiene tablas secundarias y probablemente nunca lo hará, la mayoría de esto es discutible y agregar un número entero de pk es solo una pérdida de tiempo y espacio.
Podría tener parentId, como documentos relacionados que tendrían un Id, doc1 se relaciona con doc2 etc ... Utilizará VarChar (36) como primario y establecerlo en un índice único. – 001
¿Qué pasa con el tipo de datos como identificador único, va a ser lo mismo que varchar (36)? – 001
Los GUID son un problema completamente diferente. No son datos varchar, tienen su propio tipo de datos de uniqueIdentifier. Debe investigar los problemas con el uso de GUID como PK, pero el más importante es asegurarse de NUNCA utilizarlos como el índice agrupado que PK es de forma predeterminada.Hay mucha información sobre esto, solo "Problemas de PK del GUID de SQL de Google". – HLGEM
Me doy cuenta de que llego un poco tarde a la fiesta aquí, pero pensé que sería útil elaborar un poco sobre las respuestas anteriores.
No es siempre mal usar un VARCHAR() como clave principal, pero casi siempre es. Hasta ahora, no he encontrado un momento en el que no pudiera encontrar un campo de clave principal de tamaño fijo mejor.
VARCHAR requiere más procesamiento que un entero (INT) o un campo corto de char de longitud fija (CHAR).
Además de almacenar bytes adicionales que indican la longitud "real" de los datos almacenados en este campo para cada registro, el motor de base de datos debe realizar un trabajo adicional para calcular la posición (en memoria) de los bytes inicial y final de el campo antes de cada lectura.
Las claves foráneas también deben usar el mismo tipo de datos que la clave primaria de la tabla primaria referenciada, por lo que se procesan más compuestos cuando se unen tablas para la salida.
Con una pequeña cantidad de datos, este procesamiento adicional no es probable que se note, pero a medida que crece una base de datos, comenzará a ver la degradación.
Ha dicho que está utilizando un GUID como clave, por lo que sabe de antemano que la columna tiene una longitud fija. Este es un buen momento para usar un campo CHAR (36) de longitud fija, lo que implica una sobrecarga de procesamiento mucho menor.
¿Qué longitud 'varchar'? ¿Puedes dar un par de ejemplos de claves propuestas también? –
¿Cómo elegirán los usuarios un documento para su recuperación? – Mark
la longitud del varchar es 36, para guid. El Guid como varchar se usa como clave principal. – 001