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

8

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?

Tulains Córdova
fuente
"autoritario" puede ser un término mejor que "canónico". El último término implica que estamos discutiendo un proyecto en particular o una filosofía con nombre, en lugar de una regla general de diseño de base de datos.
DougM
66
Bueno, no conozco una fuente canónica, pero, según mi experiencia, "todos los PK deben ser sustitutos", para ser precisos, "el PK debe ser siempre un campo autogenerado llamado TablenameID" funciona muy, muy bien. Lo he visto trabajando en la práctica con una base de datos de tamaño empresarial con más de 500 tablas, y desde entonces lo uso para modelar bases de datos siempre que sea posible.
Doc Brown
2
Respuestas: 1) ¡No! 2) ¡Aún más grande NO !
nvogel
55
Tengo que darle a esta pregunta un gran -1. El hecho de que dbms no requiera claves sustitutas es un indicador de que no son "imprescindibles". Dicho esto, como otros han señalado, usarlos consistentemente es una idea inteligente y ayuda a evitar complicaciones en el futuro a medida que cambian los datos.
GrandmasterB
La palabra "sustituto" se usa en más de un sentido en este contexto. En el uso inicial, una clave natural se describía como un sustituto de una entidad. Las entidades, como las personas o los aviones, no ingresan realmente en la base de datos. No son datos. La clave natural identifica una entidad y son datos. Por lo tanto, puede representar la entidad dentro de la base de datos. Siempre que, por supuesto, la empresa no administre mal la clave natural. El uso posterior utiliza la palabra "sustituto" en el sentido de que una clave artificial se utiliza como sustituto de la clave natural.
Walter Mitty el

Respuestas:

9

"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.

nvogel
fuente
Excelente respuesta. Hay mucho más que decir sobre este puntaje, pero hacer que su respuesta sea más larga no lo hubiera mejorado. Resumiste bien los puntos esenciales.
Walter Mitty el
13

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

Robert Harvey
fuente
2
@Bobson: Ya dije en mi respuesta que hay opiniones discrepantes, y estoy de acuerdo con su posición en el párrafo debajo de la declaración que citó, por lo que su voto negativo parece ... caprichoso.
Robert Harvey
2
"No se supone que las claves primarias y extranjeras sean legibles". !! ¿Quién exactamente "supone" tal cosa, aparte de Robert? La pregunta es sobre el modelo relacional que ciertamente nunca, nunca supuso tal cosa.
nvogel
3
@sqlvogel [suspiro] Hazlos legibles si lo deseas. Realmente está bien. Siempre que pueda garantizar la inmutabilidad y la unicidad, puede pintarlas de verde por todo lo que me importa. Mi punto es que la legibilidad es realmente baja en la escala de importancia.
Robert Harvey
2
@RobertHarvey Por supuesto. No hay objeción a escuchar sus opiniones tampoco, pero su primera oración se lee demasiado como si estuviera afirmando alguna propiedad o intención implícita de esas cosas. Nuevamente, como otros ya dijeron, "la inmutabilidad" no es un requisito. La estabilidad (un término relativo no absoluto) es un atributo de clave útil o deseable; la inmutabilidad no es y es de todos modos ilusoria.
nvogel
3
@RobertHarvey, si no está familiarizado con situaciones en las que no usar un sustituto es una mejor opción, algunas personas podrían concluir que no está en mejores condiciones para aconsejar cuándo o cuándo no usarlas. No tengo intención de comentar nada escrito en Witless-pedia.
nvogel