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

Antecedentes

El enfoque de "todos los PK deben ser sustitutos" no está presente en el modelo relacional de Codd ni en ningún estándar SQL (ANSI, ISO u otro).

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

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

PPDM (Professional Petroleum Data Management Association) recomienda los mismos libros canónicos:

Utilice las claves sustitutas como claves principales cuando:

1. No existen claves naturales o comerciales.
2. Las claves naturales o comerciales son malas (cambiar a menudo)
3. El valor de la clave natural o comercial no se conoce al momento de insertar el registro
4. Las claves naturales de varias columnas (generalmente varias FK) superan las tres columnas, lo que hace que las combinaciones sean demasiado detalladas.

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

Menciono PPDM porque estas personas también deben saber una o dos cosas sobre el diseño RDBMS.

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

Es cierto que el enfoque permite un modelado rápido de la base de datos al no tener que hacer mucho análisis comercial, pero a expensas de la facilidad de mantenimiento y la 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 RDBMS) a expensas de la tarea diaria 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 directo (debido a la necesidad de evitar colisiones PK y tener que crear tablas de escenario / equivalencia de antemano).

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

Las preguntas

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

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

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

En primer lugar, piense en lo que se entiende por "clave primaria" en este contexto. En el modelo relacional no hay claves "primarias", lo que significa que no hay una clave que sea fundamentalmente diferente de cualquier otra clave de la misma tabla. En principio, todas las claves en una base de datos relacional pueden y disfrutan del mismo estado 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. La selección de cualquier tecla en una tabla con varias teclas es, por lo tanto, esencialmente arbitraria (esa fue la palabra utilizada por EFCodd), subjetiva y puramente psicológica (la opinión de Chris Date, el colega y colaborador de Codd). A menos que se explique qué distinción se establece entre una clave "primaria" y cualquier otra clave, por lo tanto no tiene sentido y no tiene ningún mérito afirmar que dicha clave "

En segundo lugar, el argumento tiene muy poco que ver con los índices, que son una función 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" son o deberían ser diferentes a otras claves (ver párrafo anterior). Podríamos suponer razonablemente que, independientemente de las estructuras de almacenamiento que se utilicen, la sobrecarga de almacenamiento será, en cierta medida, mayor con una clave sustituta que sin dicha clave, pero como siempre la mejor respuesta aquí es "depende". Las decisiones de almacenamiento se deben tomar caso por caso y las reglas generales son de muy poca ayuda.

En tercer lugar, desde un punto de vista lógico , el requisito absoluto de una clave sustituta tiene muy poco sentido. El requisito de una clave natural es exactamente el mismo con o sin un sustituto. 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 la misma. Sí, es posible que sea necesario actualizar las claves, pero esa es la naturaleza de las cosas a veces. Agregar un sustituto en sí mismo no necesariamente hace que las actualizaciones clave sean más fáciles de manejar y, a veces, puede hacerlas más difíciles.

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

Naturalmente, si hay una clave natural apropiada que nunca cambiará (afirmo que son tan raros como los dientes de gallina o los tréboles de cuatro hojas, pero ...), puede usar eso, y algunos clientes harán que sea uno de sus requisitos .

Pero, ¿por qué agregar la complejidad adicional a un sistema de base de datos, para un beneficio poco apreciable? Las claves sustitutas primarias se generan por el sistema, se garantiza que son únicas, se garantiza que nunca cambiarán y son del 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 al otro lado del pasillo que defenderán viciosamente su uso de claves compuestas naturales con índices agrupados como claves primarias, 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