Que usar como clave primaria?

[hks123]

Despues de diseñar varias BD donde dejo como primary key un id autoincremental, me sigue dando vueltas en la cabeza si es lo correcto.

Es buena practica dejar como PK, un entero autoincremental gestionado por el Motor de Base de Datos sobre el cual no tenemos control???

O es mejor utilizar claves (que sabemos que son unicas) gestionadas por nosotros. Por ejemplo el DNI en una tabla personas (asumiendo que es unico), el codigo de tres letras standarizado en la tabla PAISES, etc. Esto facilitaria portablidad en las tablas y comunicacion con otros sistemas a traves de APIs.

Espero sus sugerencias.

[matanga]

El debate PK Natural (DNI de Personas, Código de País, CUIT de Clientes, etc) vs. PK Sustituta (Numérico incremental) no tiene fin, encontrarás muchas opiniones diferentes y todas con argumentos válidos, según mi experiencia, no hay una regla para afirmar que una es mejor que otra, en vez, se debe analizar cada caso particular y elegir la más óptima en función de sus características.

1. Espacio. En general, una PK Natural está representada por un campo tipo char/varchar de longitud fija (en algunos países el dni tiene letras), y una PK Sustituta está representada por un campo tipo int de longitud variable.

1.1. La PK Sustituta es más eficiente cuando existen muchas tablas que la referencian, ya que se ocupa menos espacio en las foreign key, por ejemplo:

Código:

--menor espacio con fk's tipo int
Personas ( id_persona int, dni varchar(10), nombre varchar(10) )
Empleados (id_persona int, cargo varchar(10) )
OtrasTablas ( id_persona int )

vs

--mayor espacio con fk's tipo varchar(10)
Personas ( dni varchar(10), nombre varchar(10) )
Empleados ( dni varchar(10), cargo varchar(10) )
OtrasTablas ( dni varchar(10) )

1.2. La PK Natural es más eficiente en tablas de gran tamaño que no tengan referencias, por ejemplo la tabla Facturas de un datawarehouse con millones de registros, donde agregar un campo id_factura ocupa espacio innecesario si ya tienes un campo número_factura.

2. Valor. El principio básico de una PK es que su valor sea inmutable (no cambie).

2.1. La PK Sustituta es más eficiente cuando existe la posibilidad de que el valor de la PK Natural cambie, en el ejemplo de Personas, si el dni es un dato que ingresa el usuario y por un error humano es necesario cambiarlo.

2.2. La PK Natural es más eficiente cuando no existe la posibilidad de que su valor cambie, por ejemplo la tabla Países donde el código de país es un estándar y no pueda ser modificado por el usuario.

3. Rendimiento. En general, la PK es el campo que más se utiliza para resolver las consultas.

3.1. La PK Sustituta, al ser de tipo int, es más eficiente que una PK Natural de tipo char/varchar para resolver joins con las tablas que la relacionan, por ejemplo:

Código:

--join por id_persona tipo int
select *
from 
 personas, empleados
where 
 personas.id_persona = empleados.id_persona

vs

--join por dni de tipo varchar
select *
from 
 personas, empleados
where 
 personas.dni = empleados.dni

3.2. La PK Natural es más eficiente cuando se la utiliza en el filtro where, por ejemplo, para resolver la consulta:

Código:

select *
from
 personas
where
 dni = '12345N'

--tienes dos índices, uno por id_persona y otro por dni 
Personas ( id_persona int, dni varchar(10), nombre varchar(10) )

--un solo índice para dni 
Personas ( dni varchar(10), nombre varchar(10) )

Es buena practica dejar como PK, un entero autoincremental gestionado por el Motor de Base de Datos sobre el cual no tenemos control???

Si, cuando te decides por una PK Sustituta, lo mejor es utilizar un entero autoincremental gestionado por el motor.

Saludos

[hks123]

Estimado, exelente su explicacion y muy util.
Muchas Gracias

[gnzsoloyo]

Hay detalles de a considerar.

La PK autoincremental causa problemas cuando:
- Se debe integrar diferentes instancias de una misma base de datos, ya que es usual que las mismas numeraciones se repitan en diferentes bases para la misma entidad.
- En la reintegración de datos de un backup no incremental, porque el reinicio de las numeraciones solapa valores presentes en el backup..

Además:
- Cualquier JOIN realizado con una PK Natural, como dice @matanga, puede ser muy eficiente siendo numérico. Pero si los datos a buscar ya están contenidos en la PK, es más eficiente usar la PK natural por cuanto en lugar de leer la tabla, lee el índice. En cambio si se busca por la PK Sustituta, requiere lectura de datos a tabla luego de realizar el JOIN...

En definitiva, es una discusión aún no terminada.

[matanga]

Iniciado por gnzsoloyo

La PK autoincremental causa problemas cuando:
- Se debe integrar diferentes instancias de una misma base de datos, ya que es usual que las mismas numeraciones se repitan en diferentes bases para la misma entidad.

Muy buena observación, las validaciones de datos en procesos de integración, merge o importación son un dolor de cabeza sin una PK Natural.

Saludos