¿Existe una fuente canónica que apoye a los "todos sustitutos"?

Question

Fondo

El "todos-PK-deben-ser-sustitutos" El enfoque no está presente en Modelo relacional de Codd o cualquier Estándar SQL (ANSI, ISO u otros).

Los libros canónicos también parecen eludir estas restricciones.

El propio esquema de diccionario de datos de Oracle utiliza claves naturales en algunas tablas y claves sustitutas en otras tablas.Menciono esto porque estas personas deben saber un par de cosas sobre el diseño de RDBMS.

PPDM (Asociación Profesional de Gestión de Datos del Petróleo) recomiendan los mismos libros canónicos:

Utilice claves sustitutas como claves principales cuando:

1. No existen claves naturales ni empresariales
2. Las claves naturales o comerciales son malas (cambian con frecuencia)
3. El valor de la clave natural o comercial no se conoce en el momento de insertar el registro.
4. Las claves naturales de varias columnas (normalmente varias FK) superan las tres columnas, lo que hace que las uniones sean demasiado detalladas.

Además, no he encontrado una fuente canónica que diga que las claves naturales deben ser inmutables. Lo único que encuentro es que deben ser muy estables, es decir, deben cambiarse sólo en muy raras ocasiones, si es que alguna vez.

Menciono PPDM porque estas personas también deben saber un par de cosas sobre el diseño de RDBMS.

Los orígenes del enfoque de "todos los sustitutos" parecen provenir de recomendaciones de algunos marcos ORM.

Es cierto que el enfoque permite modelado rápido de bases de datos al no tener que hacer mucho análisis de negocio, pero a expensas de la mantenibilidad y legibilidad del código SQL.Se hace mucha previsión para algo que puede suceder o no en el futuro (la PK natural cambió, por lo que tendremos que usar la funcionalidad de actualización en cascada de RDBMS) a expensas de las tareas del día a día, como tener que unir más tablas en cada consultar y tener que escribir código para importar datos entre bases de datos, un procedimiento que de otro modo sería muy sencillo (debido a la necesidad de evitar colisiones PK y tener que crear tablas de etapa/equivalencia de antemano).

Otro argumento es que los índices basados ​​en números enteros son más rápidos, pero eso debe respaldarse con puntos de referencia.Obviamente, los varchars largos y variables no son buenos para PK.Pero los índices basados ​​en varchar cortos y de longitud fija son casi tan rápidos como los números enteros.

Las preguntas

- ¿Existe alguna fuente canónica que respalde el enfoque de "todos los PK deben ser sustitutos"?

- ¿El modelo relacional de Codd ha sido reemplazado por un modelo relacional más nuevo?

Answer 1

"Todos los PK son sustitutos" no es una estrategia muy sólida en absoluto y ciertamente no es uno en el que sea probable que encuentre una fuente "autorizada" para.

En primer lugar, piense en lo que se entiende por "clave primaria" en este contexto.En el modelo relacional no hay claves "primarias", es decir, ninguna clave que sea fundamentalmente diferente de cualquier otra clave de la misma tabla.En principio, todas las claves de una base de datos relacional pueden disfrutar y disfrutan del mismo estatus y tienen las mismas características y funciones, excepto en la medida en que el diseñador de la base de datos decida lo contrario.Por lo tanto, seleccionar una clave cualquiera en una tabla con múltiples claves es esencialmente arbitrario (esa fue la palabra utilizada por E.F. Codd), subjetivo y puramente psicológico (la opinión de Chris Date, colega y colaborador de Codd).A menos que se explique qué distinción se hace entre una clave "primaria" y cualquier otra clave, carece de sentido y no tiene ningún mérito afirmar que dicha clave "debería" o "debe" ser algo.

En segundo lugar, el argumento tiene muy poco que ver con los índices, que son una característica de almacenamiento físico.Las claves son una cuestión lógica, no física, y no hay ninguna razón absoluta para suponer que las consideraciones de almacenamiento de una clave "primaria" sean o deban ser diferentes a las de otras claves (consulte el párrafo anterior).Podríamos suponer razonablemente que cualesquiera que sean las estructuras de almacenamiento que se utilicen, los gastos generales de almacenamiento serán en cierta medida mayor que con una clave sustituta que sin dicha clave, pero como siempre la mejor respuesta aquí es "depende".Las decisiones sobre el almacenamiento deben tomarse caso por caso y las reglas generales son de muy poca ayuda.

En tercer lugar, desde un lógico Desde este punto de vista, el requisito absoluto de una clave sustituta tiene muy poco sentido.El requisito de una clave natural es exactamente el mismo con o sin una madre sustituta.La necesidad de que la información sea identificable en el dominio del discurso (es decir,con una clave natural, también conocida como "clave comercial", "clave de dominio") es lo mismo.Sí, es posible que sea necesario actualizar las claves, pero a veces esa es la naturaleza de las cosas.Agregar un sustituto no necesariamente hace que las actualizaciones clave sean más fáciles de manejar y, a veces, puede hacerlas más difíciles.

Answer 2

Las llaves primarias y extrañas no tienen que ser legibles. Su propósito es mantener la estructura relacional interna de la base de datos, para no ser leída por un humano.

Naturalmente, si hay una clave natural adecuada que será nunca cambio (reclamo que estos son tan raros como los dientes de la gallina o los tréboles de cuatro hojas, pero ...), puedes usar eso, y algunos clientes harán que uno de sus requisitos.

¿Pero por qué agregar la complejidad adicional a un sistema de base de datos, por poco beneficio apreciable? Las claves sustitutas primarias se generan generadas por el sistema, garantizadas para ser únicas, garantizadas para nunca cambiar, y son el mismo tipo de datos para todas las tablas. Tendrán el mismo comportamiento confiable en todas las circunstancias.

Si está buscando un recurso canónico que respalde esta práctica, no encontrará uno. Hay tantos diseñadores en el otro lado del pasillo que defenderá viciosamente su uso de claves naturales y compuestas con índices agrupados como claves principales, y todos los recursos canónicos dicen que es la elección del diseñador.

ver también
http://en.wikipedia.org/wiki/surrogate_key