¿Por qué se debe hacer explícita una clave?

Soy muy nuevo en el tema de las bases de datos, por lo que esto puede parecer ignorante, pero tengo curiosidad por qué una clave debe hacerse explícita dentro de una tabla. ¿Esto es principalmente para decirle al usuario que el valor de la columna dada es (con suerte) garantizado para ser único dentro de cada fila? La singularidad aún debería estar allí, incluso si no se menciona.

Obviamente, ¿está sugiriendo que CONSTRAINTlas aplicaciones que tienen acceso a esa base de datos deben aplicar s en una base de datos?

Hay muchas razones por las cuales esta es una mala idea (mala, mala ...).

1) Si está construyendo un "motor de" restricción "" (es decir, dentro de su código de aplicación), simplemente está emulando lo que Oracle / SQL Server / MySQL / PostgreSQL / <. Whoever ...> ha gastado años escribiendo. Su código CONSTRAINT ha sido probado durante esos años por millones de usuarios finales.

2) Con el debido respeto hacia usted y su equipo, no lo hará bien en cuestión de años: desde aquí , el código MySQL solo cuesta 40 millones de dólares. Y MySQL es el más barato de los 3 servidores anteriores, y ni siquiera implementan CHECK CONSTRAINT. Obviamente, obtener RI (Integridad referencial) completamente correcto es difícil.

Solía ​​frecuentar los foros de Oracle y no puedo decirle la cantidad de veces que un administrador / programador pobre ha tenido un proyecto en el que el genio que tenía su trabajo antes tuvo la idea "brillante" de hacer lo que usted sugiere. .

Jonathan Lewis (escribió un libro de 550 páginas sobre los fundamentos del optimizador de Oracle ) dice que no. 2 de sus Desastres de diseño en otro libro (" Tales of the Oak Table " - The Oak Table es un grupo de expertos de Oracle) es

2. Verificaremos la integridad de los datos a nivel de aplicación en lugar de aprovechar las capacidades de comprobación de restricciones de Oracle.

3) Incluso si por algún milagro puede implementar adecuadamente RI, tendrá que volver a implementarlo por completo una y otra vez para cada aplicación que toque esa base de datos, y si sus datos son importantes, entonces las nuevas aplicaciones lo harán. Elegir esto como paradigma los llevará a usted y a sus compañeros programadores (sin mencionar el personal de soporte y las ventas) a una vida de constante lucha contra incendios y miseria.

Puede leer más acerca de por qué implementar restricciones de datos a nivel de aplicación es una locura aquí , aquí y aquí .

Para responder específicamente a su pregunta:

¿Por qué se declaran en absoluto? Parece muy útil, pero ¿es realmente necesario tener una base de datos que funcione?

La razón por la que KEYs (ya sea PRIMARY, FOREIGN, UNIQUEo simplemente normal INDEXen) se declaran es que, si bien es no es estrictamente necesario para una base de datos para tenerlos para que funcione, es absolutamente necesario para que puedan ser declaradas para que funcione bien .

Cuando crea una clave en una base de datos, el motor DBMS impone una restricción de unicidad en los atributos clave. Esto sirve al menos para tres propósitos relacionados:

• Integridad de los datos: los datos duplicados no se pueden ingresar en los atributos clave. Por lo tanto, cualquier dependencia de las claves está garantizada.
• Identificación: los usuarios pueden confiar en las claves como un medio para identificar y actualizar los datos con precisión.
• Optimización: la información (metadatos) sobre qué atributos son únicos está disponible para el optimizador de consultas DBMS. Esta información permite al optimizador simplificar la ejecución de consultas de ciertas maneras para que las consultas se ejecuten más rápido.

Agregaré un aspecto a las excelentes respuestas existentes: Documentación. A menudo es importante ver qué tipos de claves puede usar para identificar una entidad. Cualquier combinación de columnas únicas es una clave candidata.

La clave principal tiende a ser un concepto especialmente útil en la práctica.

Ya sea que aplique una clave o no (probablemente debería), la documentación es valiosa por derecho propio.

Otra razón por la que debería usar CONSTRAINT en lugar de algún código de aplicación interno:

¿Qué sucede si un desarrollador / dba usa una instrucción de inserción / actualización / eliminación para modificar los datos directamente en la base de datos? En este caso, toda su buena integridad referencial basada en aplicaciones será inútil. Lo sé, a algunos desarrolladores les gusta la posibilidad de modificar datos directamente sin tener que molestarse con RI porque saben lo que hacen, al menos la mayor parte del tiempo (pero no siempre)

PD: Por supuesto, podrías crear disparadores, pero generalmente son terriblemente lentos (en comparación con las RESTRICCIONES).