¿Qué tiene de especial la clave primaria?
¿Cuál es el propósito de una tabla en un esquema? ¿Cuál es el propósito de una clave de una tabla? ¿Qué tiene de especial la clave primaria? Las discusiones sobre las claves primarias parecen perder el punto de que la clave primaria es parte de una tabla, y esa tabla es parte de un esquema. Lo que es mejor para la tabla y las relaciones de la tabla debe conducir la clave que se utiliza.
Las tablas (y las relaciones entre tablas) contienen datos sobre la información que desea registrar. Estos hechos deben ser independientes, significativos, fáciles de entender y no contradictorios. Desde una perspectiva de diseño, otras tablas agregadas o eliminadas de un esquema no deberían afectar la tabla en cuestión. Debe haber un propósito para almacenar los datos relacionados solo con la información misma. Comprender lo que se almacena en una tabla no debería requerir someterse a un proyecto de investigación científica. Ningún hecho almacenado para el mismo propósito debe almacenarse más de una vez. Las claves son una parte o la totalidad de la información que se registra, que es única, y la clave principal es la clave especialmente designada que será el punto de acceso principal a la tabla (es decir, debe elegirse por la consistencia y el uso de los datos, no solo insertar actuación).
- Aparte: El desafortunado efecto secundario de la mayoría de las bases de datos diseñadas y desarrolladas por los programadores de aplicaciones (que a veces soy) es que lo mejor para la aplicación o el marco de la aplicación a menudo impulsa la elección de la clave principal para las tablas. Esto conduce a claves enteras y GUID (ya que son fáciles de usar para marcos de aplicaciones) y diseños de tablas monolíticas (ya que reducen el número de objetos de marco de aplicaciones necesarios para representar los datos en la memoria). Estas decisiones de diseño de bases de datos basadas en aplicaciones conducen a problemas significativos de consistencia de datos cuando se usan a escala. Los marcos de aplicación diseñados de esta manera conducen naturalmente a diseños de tabla a la vez. Los "registros parciales" se crean en tablas y datos completados con el tiempo. Se evita la interacción de varias tablas o cuando se usa causa datos inconsistentes cuando la aplicación funciona incorrectamente. Estos diseños conducen a datos sin sentido (o difíciles de entender), datos distribuidos en tablas (debe mirar otras tablas para tener sentido de la tabla actual) y datos duplicados.
Se dijo que las claves primarias deberían ser tan pequeñas como sea necesario. Diría que las claves deberían ser tan grandes como sea necesario. Se debe evitar agregar aleatoriamente campos sin sentido a una tabla. Es aún peor crear una clave a partir de un campo sin sentido agregado al azar, especialmente cuando destruye la dependencia de unión de otra tabla a la clave no primaria. Esto solo es razonable si no hay buenas claves candidatas en la tabla, pero este hecho seguramente es un signo de un diseño de esquema deficiente si se usa para todas las tablas.
También se dijo que las claves primarias nunca deberían cambiar, ya que la actualización de una clave primaria siempre debe estar fuera de discusión. Pero la actualización es lo mismo que eliminar seguido de insertar. Según esta lógica, nunca debe eliminar un registro de una tabla con una clave y luego agregar otro registro con una segunda clave. Agregar la clave primaria sustituta no elimina el hecho de que exista la otra clave en la tabla. La actualización de una clave no primaria de una tabla puede destruir el significado de los datos si otras tablas dependen de ese significado a través de una clave sustituta (por ejemplo, una tabla de estado con una clave sustituta que tiene la descripción del estado cambiada de 'Procesado' a 'Cancelado' 'definitivamente corrompería los datos). Lo que siempre debe estar fuera de discusión es destruir el significado de los datos.
Dicho esto, estoy agradecido por las muchas bases de datos mal diseñadas que existen en las empresas de hoy (gigantes sin sentido-sustitutos-datos-corruptos-1NF), porque eso significa que hay una cantidad interminable de trabajo para las personas que entienden el diseño adecuado de la base de datos . Pero, por el lado triste, a veces me hace sentir como Sísifo, pero apuesto a que tenía 401k (antes del accidente). Manténgase alejado de blogs y sitios web para preguntas importantes de diseño de bases de datos. Si está diseñando bases de datos, busque CJ Date. También puede hacer referencia a Celko para SQL Server, pero solo si se tapa la nariz primero. En el lado de Oracle, haga referencia a Tom Kyte.