¿Clave primaria o índice único?

En el trabajo tenemos una gran base de datos con índices únicos en lugar de claves primarias y todo funciona bien.

Estoy diseñando una nueva base de datos para un nuevo proyecto y tengo un dilema:

En la teoría DB, la clave primaria es un elemento fundamental, está bien, pero en proyectos REALES, ¿cuáles son las ventajas y desventajas de ambos?

¿Qué utilizas en proyectos?

EDITAR: ... y ¿qué pasa con las claves principales y la replicación en el servidor MS SQL?

¿Qué es un índice único?

Un índice único en una columna es un índice en esa columna que también impone la restricción de que no puede tener dos valores iguales en esa columna en dos filas diferentes. Ejemplo:

CREATE TABLE table1 (foo int, bar int);
CREAR ÍNDICE ÚNICO ux_table1_foo EN la tabla1 (foo); - Crear un índice único en foo.

INSERTE EN LA TABLA 1 (foo, bar) VALORES (1, 2); -- OKAY
INSERTE EN LA TABLA 1 (foo, bar) VALORES (2, 2); -- OKAY
INSERTE EN LA TABLA 1 (foo, bar) VALORES (3, 1); -- OKAY
INSERTE EN LA TABLA 1 (foo, bar) VALORES (1, 4); - ¡Falla!

Entrada duplicada '1' para la clave 'ux_table1_foo'

La última inserción falla porque viola el índice único en la columna foocuando intenta insertar el valor 1 en esta columna por segunda vez.

En MySQL, una restricción única permite múltiples NULL.

Es posible hacer un índice único en varias columnas.

Clave primaria versus índice único

Cosas que son iguales:

• Una clave primaria implica un índice único.

Cosas que son diferentes:

• Una clave primaria también implica NO NULL, pero un índice único puede ser anulable.
• Solo puede haber una clave principal, pero puede haber múltiples índices únicos.
• Si no hay un índice agrupado definido, la clave principal será el índice agrupado.

Puedes verlo así:

Una clave primaria es única

Un valor único no tiene que ser la representación del elemento

¿Sentido?; Bueno, se usa una clave principal para identificar el elemento, si tiene una "Persona", le gustaría tener un Número de Identificación Personal (SSN o tal) que sea Primario para su Persona.

Por otro lado, la persona puede tener un correo electrónico que es único, pero no identifica a la persona.

Siempre tengo claves primarias, incluso en las tablas de relaciones (la tabla media / tabla de conexión) podría tenerlas. ¿Por qué? Bueno, me gusta seguir un estándar al codificar, si la "Persona" tiene un identificador, el Coche tiene un identificador, bueno, ¡la Persona -> Coche también debería tener un identificador!

Las claves foráneas funcionan con restricciones únicas, así como las claves primarias. De libros en línea:

Una restricción FOREIGN KEY no tiene que estar vinculada solo a una restricción PRIMARY KEY en otra tabla; también se puede definir para hacer referencia a las columnas de una restricción ÚNICA en otra tabla

Para la replicación transaccional, necesita la clave primaria. De libros en línea:

Las tablas publicadas para la replicación transaccional deben tener una clave primaria. Si una tabla está en una publicación de replicación transaccional, no puede deshabilitar ningún índice asociado con columnas de clave principal. Estos índices son necesarios para la replicación. Para deshabilitar un índice, primero debe descartar la tabla de la publicación.

Ambas respuestas son para SQL Server 2005.

La elección de cuándo usar una clave primaria sustituta en lugar de una clave natural es complicada. Respuestas como, siempre o nunca, rara vez son útiles. Me parece que depende de la situación.

Como ejemplo, tengo las siguientes tablas:

CREATE TABLE toll_booths (
    id            INTEGER       NOT NULL PRIMARY KEY,
    name          VARCHAR(255)  NOT NULL,
    ...
    UNIQUE(name)
)

CREATE TABLE cars (
    vin           VARCHAR(17)   NOT NULL PRIMARY KEY,
    license_plate VARCHAR(10)   NOT NULL,
    ...
    UNIQUE(license_plate)
)

CREATE TABLE drive_through (
    id            INTEGER       NOT NULL PRIMARY KEY,
    toll_booth_id INTEGER       NOT NULL REFERENCES toll_booths(id),
    vin           VARCHAR(17)   NOT NULL REFERENCES cars(vin),
    at            TIMESTAMP     DEFAULT CURRENT_TIMESTAMP NOT NULL,
    amount        NUMERIC(10,4) NOT NULL,
    ...
    UNIQUE(toll_booth_id, vin)
)

Tenemos dos tablas de entidades ( toll_boothsy cars) y una tabla de transacciones ( drive_through). La toll_boothtabla utiliza una clave sustituta porque no tiene ningún atributo natural que no se garantiza que cambie (el nombre se puede cambiar fácilmente). La carstabla usa una clave primaria natural porque tiene un identificador único que no cambia ( vin). La drive_throughtabla de transacciones utiliza una clave sustituta para una fácil identificación, pero también tiene una restricción única sobre los atributos que se garantiza que son únicos en el momento en que se inserta el registro.

http://database-programmer.blogspot.com tiene algunos excelentes artículos sobre este tema en particular.

No hay desventajas de las claves primarias.

Para agregar solo algo de información a las respuestas de @MrWiggles y @Peter Parker, cuando la tabla no tiene clave principal, por ejemplo, no podrá editar datos en algunas aplicaciones (terminarán diciendo que algo así no puede editar / eliminar datos sin Clave primaria). Postgresql permite que múltiples valores NULL estén en una columna ÚNICA, PRIMARY KEY no permite NULLs. Además, algunos ORM que generan código pueden tener algunos problemas con las tablas sin claves principales.

ACTUALIZAR:

Hasta donde sé, no es posible replicar tablas sin claves primarias en MSSQL, al menos sin problemas ( detalles ).

Si algo es una clave primaria, dependiendo de su motor de base de datos, toda la tabla se ordena por la clave primaria. Esto significa que las búsquedas son mucho más rápidas en la clave primaria porque no tiene que hacer ninguna desreferenciación, ya que tiene que ver con cualquier otro tipo de índice. Además de eso, es solo teoría.

Además de lo que han dicho las otras respuestas, algunas bases de datos y sistemas pueden requerir una presencia primaria. Me viene a la mente una situación; Cuando se utiliza la replicación empresarial con Informix, debe haber una PK para que una tabla participe en la replicación.

Siempre que no permita NULL para un valor, deben manejarse de la misma manera, pero el valor NULL se maneja de manera diferente en las bases de datos (AFAIK MS-SQL no permite más de un (1) valor NULL, mySQL y Oracle lo permiten , si una columna es ÚNICA) Por lo tanto, debe definir esta columna NO NULO ÍNDICE ÚNICO

No existe una clave principal en la teoría de datos relacionales, por lo que su pregunta debe responderse a nivel práctico.

Los índices únicos no son parte del estándar SQL. La implementación particular de un DBMS determinará cuáles son las consecuencias de declarar un índice único.

En Oracle, declarar una clave primaria dará como resultado la creación de un índice único en su nombre, por lo que la pregunta es casi discutible. No puedo contarte sobre otros productos DBMS.

Estoy a favor de declarar una clave primaria. Esto tiene el efecto de prohibir NULL en la (s) columna (s) clave (s), así como prohibir duplicados. También estoy a favor de declarar restricciones de REFERENCIAS para hacer cumplir la integridad de la entidad. En muchos casos, declarar un índice sobre las coulmn (s) de una clave extranjera acelerará las uniones. Este tipo de índice en general no debe ser único.

Hay algunas desventajas de los ÍNDICES AGRUPADOS frente a los ÍNDICES ÚNICOS.

Como ya se dijo, un ÍNDICE CLUSTERADO ordena físicamente los datos en la tabla.

Esto significa que cuando tiene mucho si inserta o elimina en una tabla que contiene un índice agrupado, cada vez (bueno, casi, dependiendo de su factor de relleno) cambia los datos, la tabla física debe actualizarse para mantenerse ordenada.

En tablas relativamente pequeñas, esto está bien, pero al llegar a tablas que tienen el valor de GB de datos, y los insertadores / eliminaciones afectan la ordenación, se encontrará con problemas.

Casi nunca creo una tabla sin una clave primaria numérica. Si también hay una clave natural que debería ser única, también le pongo un índice único. Las uniones son más rápidas en enteros que las claves naturales de varias columnas, los datos solo necesitan cambiar en un lugar (las claves naturales tienden a actualizarse, lo que es malo cuando está en la clave primaria: relaciones de clave externa). Si va a necesitar replicación, use un GUID en lugar de un número entero, pero en su mayor parte prefiero una clave que pueda leer el usuario, especialmente si necesitan verla para distinguir entre John Smith y John Smith.

Las pocas veces que no creo una clave sustituta es cuando tengo una tabla de unión que está involucrada en una relación de muchos a muchos. En este caso, declaro ambos campos como la clave principal.

Tengo entendido que una clave primaria y un índice único con una restricción no nula son lo mismo (*); y supongo que uno elige uno u otro dependiendo de lo que la especificación explícitamente indique o implique (una cuestión de lo que desea expresar y hacer cumplir explícitamente). Si requiere unicidad y no nulo, conviértalo en una clave principal. Si sucede que todas las partes de un índice único no son nulas sin ningún requisito para ello, simplemente conviértalo en un índice único.

La única diferencia restante es que puede tener múltiples índices únicos no nulos, mientras que no puede tener múltiples claves primarias.

(*) Exceptuando una diferencia práctica: una clave primaria puede ser la clave única predeterminada para algunas operaciones, como definir una clave externa. Ex. si uno define una clave externa que hace referencia a una tabla y no proporciona el nombre de la columna, si la tabla referenciada tiene una clave primaria, entonces la clave principal será la columna referenciada. De lo contrario, la columna a la que se hará referencia deberá nombrarse explícitamente.

Otros aquí han mencionado la replicación de DB, pero no lo sé.

El índice único puede tener un valor NULL. Crea un índice no agrupado. La clave primaria no puede contener un valor NULL. Crea un índice agrupado.

En MSSQL, las claves primarias deberían aumentar de forma monotónica para obtener el mejor rendimiento en el índice agrupado. Por lo tanto, un número entero con inserción de identidad es mejor que cualquier clave natural que podría no estar aumentando monotónicamente.

Si fuera por mí...

Debe satisfacer los requisitos de la base de datos y de sus aplicaciones.

Agregar un entero de incremento automático o una columna de identificación larga a cada tabla para que sirva como clave principal se ocupa de los requisitos de la base de datos.

Luego agregaría al menos otro índice único a la tabla para que lo use su aplicación. Este sería el índice en employee_id, o account_id, o customer_id, etc. Si es posible, este índice no debería ser un índice compuesto.

Yo preferiría los índices en varios campos individualmente sobre los índices compuestos. La base de datos usará los índices de campo único siempre que la cláusula where incluya esos campos, pero solo usará un compuesto cuando proporcione los campos exactamente en el orden correcto, lo que significa que no puede usar el segundo campo en un índice compuesto a menos que proporcione tanto el primero como el segundo en su cláusula where.

Estoy a favor de usar índices calculados o de tipo Function, y recomendaría usarlos sobre índices compuestos. Hace que sea muy fácil usar el índice de función al usar la misma función en su cláusula where.

Esto se ocupa de los requisitos de su aplicación.

Es muy probable que otros índices no primarios sean, en realidad, asignaciones de los valores de clave de índices a un valor de clave primaria, no los de rowid (). Esto permite que se produzcan operaciones de ordenación física y eliminaciones sin tener que volver a crear estos índices.