Las claves primarias y externas son el pegamento que organiza múltiples tablas en una base de datos relacional eficiente. El diseño de claves primarias y claves foráneas tiene un impacto decisivo en el rendimiento y disponibilidad de la base de datos física.
El esquema de la base de datos debe convertirse de un diseño lógico teórico a un diseño físico real. La estructura de claves primarias y claves externas es el quid de este proceso de diseño. Una vez que la base de datos diseñada se utilice en un entorno de producción, será difícil modificar estas claves, por lo que es muy necesario y valioso diseñar las claves primarias y externas durante la etapa de desarrollo.
Clave primaria:
Las bases de datos relacionales se basan en claves primarias, la piedra angular del esquema físico de la base de datos. Las claves primarias solo tienen dos propósitos a nivel físico:
1. Identificar de forma única una fila.
2. Como un objeto al que se puede hacer referencia de manera efectiva mediante claves externas.
Con base en los dos usos anteriores, aquí hay algunos principios que sigo al diseñar claves primarias a nivel físico:
1. La clave principal no debe tener significado para el usuario. Si un usuario ve datos en una tabla de combinación que representa una relación de muchos a muchos y se queja de que son de poca utilidad, eso demuestra que su clave principal está bien diseñada.
2. La clave principal debe ser una sola columna para mejorar la eficiencia de las operaciones de unión y filtrado.
Nota: Las personas que utilizan claves compuestas suelen excusarse por dos razones, las cuales son erróneas. Una es que la clave principal debe tener un significado real. Sin embargo, hacer que la clave principal tenga significado solo proporciona conveniencia para destruir artificialmente la base de datos. La segunda es que puede usar este método para usar dos claves externas como claves primarias en una tabla de combinación que describe una relación de muchos a muchos. También me opongo a este enfoque porque: las claves primarias compuestas a menudo conducen a claves externas incorrectas. es decir, al unir tablas Conviértase en la tabla maestra de otra tabla esclava y forme parte de la clave principal de esta tabla de acuerdo con el segundo método anterior. Sin embargo, esta tabla puede convertirse en la tabla maestra de otras tablas esclavas y en su clave principal. puede convertirse en la tabla maestra de otras tablas esclavas como parte de la clave principal. Si se pasa de esta manera, cuanto más tarde sea la tabla esclava, más columnas contendrá su clave principal.
3. Nunca actualice las claves primarias. De hecho, dado que la clave principal no tiene otro propósito que identificar de forma única una fila, no hay razón para actualizarla. Si es necesario actualizar la clave principal, se viola el principio de que la clave principal no debe tener sentido para el usuario.
Nota: Este principio no se aplica a los datos que a menudo deben organizarse durante la conversión de datos o fusiones de múltiples bases de datos.
4. La clave principal no debe contener datos que cambien dinámicamente, como marca de tiempo, columna de hora de creación, columna de hora de modificación, etc.
5. La clave principal debe ser generada automáticamente por la computadora. Si un humano interviene en la creación de una clave primaria, tendrá un significado distinto al de identificar de forma única una fila. Una vez que se cruza este límite, puede haber un incentivo para modificar la clave principal, de modo que los medios clave utilizados por este sistema para vincular y administrar filas de registros caigan en manos de personas que no entienden el diseño de bases de datos.
Una clave externa es una restricción de integridad a nivel de base de datos, que es el método de implementación de "integridad referencial" de la base de datos mencionado en el libro de teoría básica de bases de datos.
Por supuesto, el atributo de clave externa se puede eliminar. Si ya no desea utilizar esta restricción, ciertamente no tendrá ningún impacto en la programación, pero al ingresar datos, la verificación de "integridad referencial" no se realizará en los datos ingresados. .
Por ejemplo, hay dos tablas
A(a,b): a es la clave primaria, b es la clave externa (de Bb)
B(b,c,d): b es la clave principal
Si elimino el atributo de clave externa del campo b, no tendrá ningún impacto en la programación.
Como arriba, b en A está vacío o es un valor que existe en b en B. Cuando hay una clave externa, la base de datos verificará automáticamente si b en A existe en b en B.
1. La expresión externa expresa integridad referencial: es inherente a los datos y no tiene nada que ver con el programa. Por lo tanto, debería dejarse en manos del DBMS.
2. El uso de bases de datos externas es simple e intuitivo y puede reflejarse directamente en el modelo de datos. Tiene grandes beneficios en términos de diseño, mantenimiento, etc., especialmente al analizar las bases de datos existentes. Los beneficios son muy obvios: no lo analicé. Hace mucho tiempo encontré una base de datos empresarial existente. Algunas de las restricciones de integridad referencial que contiene se describen mediante claves externas y algunas se implementan mediante activadores. Por supuesto, puede que esté en el documento, pero puede que no esté completo, pero las claves externas son muy obvias e intuitivas.
3. Dado que podemos usar disparadores o programas para completar este trabajo (refiriéndose a las restricciones de integridad referencial), DBMS ha proporcionado los medios, ¿por qué deberíamos hacerlo nosotros mismos? Y hay que decir que lo que hacemos no es tan bueno como RDBMS. De hecho, los primeros RDBMS no tenían claves externas, pero ahora todos las tienen, creo que tiene sentido que los proveedores de bases de datos agreguen esta característica. Desde esta perspectiva, las claves foráneas son más convenientes.
4. Con respecto a la conveniencia, según los proyectos que dirigí, los programadores informaron que ingresar datos durante la depuración era principalmente problemático: si los datos pueden violar la integridad referencial, entonces la integridad referencial en sí no entra en conflicto con la reputación del negocio. el programa de futuros de activación no debe usarse; de lo contrario, significa que los datos son incorrectos y no deben ingresarse en la base de datos en absoluto. Además, esto también debería formar parte del sistema de pruebas: bloquear los datos ilegales. De hecho, el programa front-end debería manejar este error de envío. Los datos pertenecen a la empresa, no al programa. Los programas almacenados deben separarse de los datos tanto como sea posible, y viceversa.
Finalmente, permítanme hablar sobre varios principios para crear claves:
1. Cree claves externas para campos relacionados.
2. Todas las claves deben ser únicas.
3. Evite el uso de claves compuestas.
4. Las claves externas siempre están asociadas con campos de clave únicos.
Este artículo proviene del blog de CSDN. Indique la fuente al reimprimir: http://blog.csdn.net/c04s31602/archive/2009/12/30/5107568.aspx .