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

7

Fondo

El "todo-PK-debe-ser-sustitutos" no está presente en Modelo relacional de Codd o en cualquier Estándar SQL (ANSI , ISO u otro).

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 una o dos cosas sobre el diseño de RDBMS.

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

Utilice claves sustitutas como claves principales cuando:

  1. No hay claves naturales o comerciales
  2. Las claves naturales o comerciales son malas (cambiar a menudo)
  3. El valor de la clave natural o de negocio 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.

Tampoco 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 muy raras ocasiones, si siempre.

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

Los orígenes del enfoque de "sustitutos de todos" 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 un análisis de negocios, sino a expensas de la capacidad de mantenimiento y legibilidad del código SQL. Se hace mucha previsión para algo que puede o no suceder en el futuro (el PK natural ha cambiado, por lo que tendremos que usar la funcionalidad de actualización en cascada de 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 por lo demás muy estricto (debido a la necesidad de evitar las colisiones PK y tener que crear tablas de etapas / equivalencias de antemano).

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

Las preguntas

: ¿hay alguna fuente canónica que admita el enfoque de "todo-PK-debe-ser-sustituto"?

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

    
pregunta Tulains Córdova 11.07.2013 - 18:25

2 respuestas

8

"Todos los PK son sustitutos" no es una estrategia muy acertada y ciertamente no es una fuente en la que puedas encontrar una fuente "autoritaria" para .

En primer lugar, piense en lo que se entiende por "clave principal" 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 tienen el mismo estado y tienen las mismas características y funciones, excepto en la medida en que el diseñador de la base de datos elija lo contrario. El hecho de seleccionar una clave en una tabla con varias claves es, por lo tanto, esencialmente arbitrario (esa era 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 está haciendo entre una clave "primaria" y cualquier otra clave, por lo tanto no tiene ningún sentido y no tiene ningún mérito para afirmar que dicha clave "debería" o "debe" ser cualquier cosa.

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 un asunto lógico, no físico 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 (consulte el 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 para una clave natural es exactamente el mismo con o sin sustituto. La necesidad de que la información sea identificable en el dominio del discurso (es decir, con una clave natural conocida como "clave comercial", "clave de dominio") es la misma. Sí, es posible que las claves deban actualizarse, pero esa es la naturaleza de las cosas a veces. 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.

    
respondido por el nvogel 11.07.2013 - 21:38
13

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

Naturalmente, si hay una clave natural apropiada que nunca cambiará (afirmo que son tan raras como los dientes de gallina o los tréboles de cuatro hojas, pero ...), puedes usar eso, y algunos clientes harán de eso 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 son generadas por el sistema, se garantiza que son únicas, se garantiza que nunca se cambiarán 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 al otro lado del pasillo que defenderán su uso viciosamente de claves naturales 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
enlace

    
respondido por el Robert Harvey 11.07.2013 - 18:36

Lea otras preguntas en las etiquetas