Int o varchar como llave primaria

[giovani_loera]

Un saludo a todos.

Tengo una duda, sobre que tipo de dato me conviene usar int o varchar como llave primaria de una tabla.

Por ejemplo
Tengo una tabla llamada Producto, cada producto tiene un codigo ( por ejemplo TRZ09) que es unico, ademas tiene un campo para describir el producto.

Mi pregunta es ti me conviene usar el codigo como llave primeria o agrego una columna llamada ID (tipo int) para usarla como llave.

La llave primaria la utilizare en varias tablas para relacionarlar.

Espero que me den sus opiniones y sus experiencias.

[ramirezmario7]

Hola.

Por facilidad seria mejor con el int ya que lo puedes colocar que se incremente automatico pero pueden llegar a cometer el error de meter el mismo producto con diferente pk.

Lo de usar el varchar seria como mas seguro porke tu sabes ke el codigo es unico y asi nunca se duplicarian los productos.
Yo para tablas de productos siempre uso el codigo del producto como la pk

[wwwmaster]

Yo acostumbro usar los numericos autoincrementables (int), para evitar duplicidad, luego tambien coloco un campo "codigo" donde el cliente puede poner el identificador de su producto, por supuesto, mediante programacion, validar que no se duplique el codigo.

Para el caso de campos string es char, no varchar, ya que varchar es un campo de texto de longitud variable, util para descripciones largas o contenidos en los que no sabes cual puede ser la longitud maxima del contenido.

Si luego creas la tabla de detalle de compras, puedes colocar ya sea el codigo o mejor, el idProducto (PK de productos), uno de los 2, por si hay un cambio en el catalogo, el PK no se modifica, solo el codigo, y el detalle de productos no se alteraria por integridad referencial.

[iislas]

No he visto, por ningun lado, restriccion alguna para manejar campos STRING como PK.

[Andres95]

Al tener una llave numerica te hace mas rapidas las consultas, sobre todo si clave de producto es grande (digamos 18-20 caracteres) y haces joins con otras tablas con mucha info.. inventarios, transacciones.. etc..

Pero bueno a veces no es practico tener el auto incrementable por lo que ya se ha mencionado en otros posts..


Sin embargo si deseas utilizarlo SQL te provee de restriccion de clave unica, para validar la consistencia de tu info..y que no halla repetidos (sin depender de la capa de programacion)...

por ejemplo:

Código:

if OBJECT_ID('tempdb..#tmpTest') is not null drop table #tmpTest

create table #tmpTest (iKey int identity(1,1) Primary key, cProduct CHAR(10) Unique  )

INSERT INTO #tmpTest VALUES('PROD01'),('PROD02'),('PROD03'),('PROD04'),('PROD05')

SELECT * FROM #tmpTest

INSERT INTO #tmpTest VALUES('PROD05')


Este ultimo truena con este mensaje..

Msg 2627, Level 14, State 1, Line 9
Violation of UNIQUE KEY constraint 'UQ__#tmpTest__368D6FC77A67F969'. Cannot insert duplicate key in object 'dbo.#tmpTest'.
The statement has been terminated.

Y como referencia..

Primary key VS Unique key in SQL Server

Saludos!

[giovani_loera]

Muchas Gracias a Todos.
Me ayudaron mucho, voy a tomar tu ejemplo Andres95 , pero es vez que se incremental are un store procedure donde adentro haga el insert pero antes de consultar el ultimo id de la tabla y sumarle +1.

Código SQL:

DECLARE @newID INT
SELECT @newID=ISNULL(MAX(ID),0)+1 FROM myTabla
 

[matanga]

Iniciado por giovani_loera

Muchas Gracias a Todos.
Me ayudaron mucho, voy a tomar tu ejemplo Andres95 , pero es vez que se incremental are un store procedure donde adentro haga el insert pero antes de consultar el ultimo id de la tabla y sumarle +1.

Entre las diferentes formas que hay para calcular un ID, el select max() puede que sea la peor, considera dos ejemplos:

Código:

declare @newId int
select @newId=isnull(max(id),0)+1 from myTabla
insert into myTabla (id) values (@newId)
go

Por un lado, con un lock por defecto, transacciones implícitas y un índice sobre el campo ID, tendrás buen rendimiento, pero no hay garantías de que funcione, ya que en entornos de alta concurrencia o tablas de gran tamaño, se podría generar el mismo valor de @newId para dos consultas ejecutadas al mismo tiempo.

Código:

declare @newId int
begin transaction
select @newId=isnull(max(id),0)+1 from myTabla with (tablock)
insert into myTabla (id) values (@newId)
commit transaction
go

Por otro lado, con un lock tipo tabla y transacciones explícitas evitas que se genere un valor duplicado para @newId, ya que en caso de dos consultas al mismo tiempo, una se ejecuta y la otra queda en espera, pero esto puede provocar bajo rendimiento en entornos de alta concurrencia.

Si el campo ID va a ser una PK sustituta tipo INT te recomiendo que utilices identity.

Saludos

[jogase20]

Es mas performante usar un tipo entero que una cadena alfanumerica :)

Para busquedas, bajas y modificaciones podrías usar el ID auto incemental, y otro campo en la misma tabla para usar el código de producto alfanumérico.

De este modo la consulta es mucho mas ligera si tuvieses 1000000 de registros ;)

Espero te sirva de ayuda

Saludos!

[ingelenalopez]

Eso que quieres hacer se llama clave "forzada", he trabajado con base de datos con miles de millones de registros y el rendimiento de tus consultas no va a depender de que un campo sea int o varchar.
25 millones de registros con un PK autoincremento o un PK alfanumérico tiene el mismo tiempo de respuesta y utiliza el mismo plan de ejecución.
Toma en cuenta que cuando el usuario realice una búsqueda lo hará por el código del producto o por su nombre, no por el identity y los índices se crean a partir de las cláusulas where que vayas a usar en las consultas.

Experiencia, 6+ años en administración de base de datos SLQ Server desde la 7 y hasta la 2008.
Consejo:
- Crea claves foráneas.
- Crea índice basándote en los filtros de la aplicación.
- Dale mantenimiento a los índices (Rebuild si IndexFragmentation > 40%; Reorganize IndexFragmentation está entre 10 y40%).
- Recompila vistas y stored procedures siempre que le hagas un alter (sp_recompile)
- Crea estadísticas

Estos, entre otras cosas, son los que te darán mejor rendimiento, el tipo de datos no influye tanto como para preocuparse por eso...

Cualquier duda estoy a las órdenes.