Sustituto vs. claves naturales / comerciales [cerrado]


174

Aquí vamos de nuevo, el viejo argumento aún surge ...

¿Será mejor que tengamos una clave comercial como clave principal, o preferiríamos tener una identificación sustituta (es decir, una identidad de SQL Server) con una restricción única en el campo de clave comercial?

Por favor, proporcione ejemplos o pruebas para apoyar su teoría.


24
@Joachim Sauer: Una discusión sobre si una cosa es subjetiva puede ser subjetiva, sin que esto se relacione de ninguna manera con la objetividad o subjetividad de la cosa en cuestión. A menos que esté preparado para establecer los criterios objetivos exactos que hacen que algo sea objetivo. Hay cosas llamadas "conceptos abiertos", como cuántos pelos se necesitan para hacer una barba. Se puede decir objetivamente que una persona sin cabello en la barbilla no tiene barba, y una con 5,000 pelos de una pulgada de largo tiene barba, pero en algún punto intermedio se requiere un juicio subjetivo para hacer una determinación objetiva.
ErikE

@Manrico: solo tienes que preguntarte esto: si no uso una clave sustituta, ¿mi clave principal seguirá siendo inmutable? Si la respuesta es no, entonces debería considerar seriamente usar una clave sustituta. Además, si la clave primaria se compone incluso parcialmente de las entradas del usuario, debería considerar usar una clave sustituta. ¿Por qué? Debido al peligro de anomalías en los datos.
code4life

@TylerRick Pero esta no es una buena pregunta. Pide una solución que sea generalmente aplicable a todas las situaciones, cuando claramente no hay una, como lo demuestra la "guerra religiosa" de la que el autor de la pregunta es perfectamente consciente (cita: "Aquí vamos de nuevo, todavía surge el viejo argumento. .. "). En lugar de preguntarse si el mundo ha cambiado y finalmente se ha proporcionado una razón convincente para elegir un lado todo el tiempo, es mejor seguir haciendo esta pregunta una y otra vez para cada situación concreta, y publicar en SO cuando no esté seguro . Esto solo provoca dogmatismo.
MarioDS

Respuestas:


97

Ambos. Toma tu pastel y cometelo.

Recuerde que no hay nada especial en una clave primaria, excepto que está etiquetada como tal. No es más que una restricción NOT NULL UNIQUE, y una tabla puede tener más de una.

Si usa una clave sustituta, aún desea una clave comercial para garantizar la unicidad de acuerdo con las reglas comerciales.


77
Si tiene varias claves "candidatas" (campos o colecciones de campos del mismo tamaño que NO SON NÚMEROS ÚNICOS), es probable que esté violando el formulario normal de Boyce-Codd. BCNF está más allá de 3NF, por lo que no mucha gente se preocupa por eso. Sin embargo, hay situaciones en las que estar en BCNF es muy útil.
Alan

2
Convenido. La verdadera pregunta debería ser: ¿Debería agregar una clave sustituta única a mis tablas? Una pregunta completamente diferente es qué usar para una clave primaria lógica. Ambas son esencialmente restricciones de índice únicas no nulas.
dkretz

1
"Cada problema se resuelve con otro nivel de indirección" ... Las claves sustitutas son solo eso: otro nivel de indirección
Steve Schnepp

55
Me parece extraño que muchos comentarios parezcan afirmar que no se puede establecer una relación sin una clave sustituta. En muchos casos, la clave sustituta es superflua. ¿Por qué agregar algo que no aporta valor sino que agrega deuda técnica (y en algunos casos, hace que un resultado que de otro modo sería único de repente no lo sea)?
Wil Moore III

2
Es más que una restricción NO NULA ÚNICA. La clave primaria se usa como un índice agrupado que determina el orden físico de sus datos. En general, Integer es fácil de equilibrar ya que aumenta secuencialmente y sus datos se agregarán al EOF en el disco. Si usa menos datos secuenciales como texto o GUID (UUID), habrá muchas más E / S de disco y esfuerzo para equilibrar el índice, creo que es una gran diferencia
Jin

124

Solo algunas razones para usar claves sustitutas:

  1. Estabilidad : Cambiar una clave debido a una necesidad comercial o natural afectará negativamente las tablas relacionadas. Las claves sustitutas rara vez, si es que alguna vez, necesitan ser cambiadas porque no hay un significado vinculado al valor.

  2. Convención : le permite tener una convención de nomenclatura de columnas de clave principal estandarizada en lugar de tener que pensar en cómo unir tablas con varios nombres para sus PK.

  3. Velocidad : dependiendo del valor y tipo de PK, una clave sustituta de un entero puede ser más pequeña, más rápida de indexar y buscar.


2
Ahora, después de leer mucho sobre las claves sustitutas y las claves naturales, creo que usar las claves sustitutas es mejor. Pero, en mi base de datos, las claves naturales (un NVARCHAR (20)) deben ser únicas. No entiendo cómo puedo obtener más velocidad si necesito verificar todos los datos en esa columna para no repetir ningún valor (usando una restricción NO NULL ÚNICA) en cada inserción.
VansFannel

70

Parece que nadie ha dicho nada en apoyo de las claves no sustitutas (dudo en decir "natural"). Entonces aquí va ...

Una desventaja de las claves sustitutas es que no tienen sentido (se cita como una ventaja para algunos, pero ...). Esto a veces te obliga a unir muchas más tablas en tu consulta de las que realmente deberían ser necesarias. Comparar:

select sum(t.hours)
from timesheets t
where t.dept_code = 'HR'
and t.status = 'VALID'
and t.project_code = 'MYPROJECT'
and t.task = 'BUILD';

en contra:

select sum(t.hours)
from timesheets t
     join departents d on d.dept_id = t.dept_id
     join timesheet_statuses s on s.status_id = t.status_id
     join projects p on p.project_id = t.project_id
     join tasks k on k.task_id = t.task_id
where d.dept_code = 'HR'
and s.status = 'VALID'
and p.project_code = 'MYPROJECT'
and k.task_code = 'BUILD';

¿A menos que alguien piense seriamente que lo siguiente es una buena idea ?:

select sum(t.hours)
from timesheets t
where t.dept_id = 34394
and t.status_id = 89    
and t.project_id = 1253
and t.task_id = 77;

"Pero" alguien dirá, "¿qué sucede cuando cambia el código de MYPROJECT o VALID o HR?" A lo que mi respuesta sería: "¿por qué necesitarías cambiarlo?" Estas no son claves "naturales" en el sentido de que algún organismo externo va a legislar que en adelante "VÁLIDO" debería volver a codificarse como "BUENO". Solo un pequeño porcentaje de las claves "naturales" realmente caen en esa categoría: el SSN y el código postal son los ejemplos habituales. Definitivamente usaría una clave numérica sin sentido para tablas como Persona, Dirección, pero no para todo , que por alguna razón la mayoría de las personas aquí parecen recomendar.

Ver también: mi respuesta a otra pregunta


14
-1 Las claves naturales como clave principal tienen el problema de que para cada tabla secundaria debe agregar la clave principal que puede estar compuesta por más de un campo (en lugar de solo uno, que es el caso de una clave sustituta) y también el elemento secundario llave. Así que imagine lo siguiente, comenzando desde TABLEA, la relación es 1-0 .. *: TABLEA PK: ID_A TABLEB PK: ID_A ID_B TABLEC PK: ID_A ID_B ID_C TABLED PK: ID_A ID_B ID_C ID_D. ¿Ves el problema? La clave principal se propaga en las tablas secundarias. ¿Qué pasaría si cambia la clave principal de TABLEA? Ahora tendría que refactorizar todas las tablas secundarias PK también.
Alfredo Osorio

9
@ Alfredo: sí, por supuesto, hay una compensación. Sin embargo, en mis más de 20 años de experiencia, rara vez he visto la definición del cambio de PK de una mesa. Si sucediera de manera regular, probablemente también evitaría las claves naturales. En realidad, en las extremadamente raras ocasiones en que esto sucede, estoy preparado para recibir el impacto del impacto extendido.
Tony Andrews

10
Estoy en desacuerdo. A menudo es el caso donde algún organismo externo (el cliente) legisla que una clave natural necesita ser editada y, por lo tanto, propagada por todo el sistema. Veo que esto sucede regularmente. La única forma en que puede estar seguro de que la clave nunca tendrá que cambiar es cuando, por definición, no tiene sentido. Además, las bases de datos modernas manejan las uniones internas de manera extremadamente eficiente, por lo que las ganancias de espacio potencialmente grandes por el uso de sustitutos generalmente superan la ventaja de no tener que hacer tantas uniones internas.
TTT

8
@TTT: Entonces, para empezar, el diseño era débil. De nuevo, ahí es donde los hombres se separan de los niños: tomar la decisión correcta de cuándo usar la llave natural y cuándo usar un sustituto. Tú decides eso por tabla, no como un dogma general.
DanMan

77
También tengo más de 20 años de experiencia, y secundo su opinión. Una vez he creado un datawarehouse oracle con claves sustitutas, y el mantenimiento de datos fue como el infierno. Simplemente nunca puede acceder directamente a sus datos. siempre necesita escribir consultas para todo, y eso hace que las claves sustitutas sean simplemente terribles de manejar.
Policía SQL

31

La clave sustituta NUNCA tendrá una razón para cambiar. No puedo decir lo mismo sobre las claves naturales. Apellidos, correos electrónicos, números ISBN: todos pueden cambiar un día.


31

Las claves sustitutas (generalmente números enteros) tienen el valor agregado de hacer que las relaciones de su tabla sean más rápidas y más económicas en el almacenamiento y la velocidad de actualización (incluso mejor, las claves externas no necesitan actualizarse cuando se usan claves sustitutas, en contraste con los campos de clave empresarial, eso cambia de vez en cuando).

La clave principal de una tabla se debe utilizar para identificar de forma exclusiva la fila, principalmente con fines de unión. Piense en una tabla de personas: los nombres pueden cambiar y no se garantiza que sean únicos.

Think Companies: eres una empresa feliz de Merkin que hace negocios con otras empresas en Merkia. Eres lo suficientemente inteligente como para no utilizar el nombre de la empresa como clave principal, por lo que utilizas el ID de empresa único del gobierno de Merkia en su totalidad de 10 caracteres alfanuméricos. Luego Merkia cambia las identificaciones de la compañía porque pensaron que sería una buena idea. Está bien, utiliza la función de actualizaciones en cascada de su motor db, para un cambio que no debería involucrarlo en primer lugar. Más tarde, su negocio se expande y ahora trabaja con una empresa en Freedonia. La identificación de la compañía Freedonian tiene hasta 16 caracteres. Debe ampliar la clave principal de identificación de la empresa (también los campos de clave externa en Pedidos, Problemas, Transferencias de dinero, etc.), agregando un campo País en la clave primaria (también en las claves externas). ¡Ay! Guerra civil en Freedonia, es ' s dividido en tres países. El nombre del país de su asociado debe cambiarse al nuevo; actualizaciones en cascada del rescate. Por cierto, ¿cuál es tu clave principal? (País, ID de empresa) o (ID de empresa, país)? El último ayuda a unirse, el primero evita otro índice (o quizás muchos, si desea que sus pedidos también se agrupen por país).

Todo esto no es una prueba, sino una indicación de que una clave sustituta para identificar de forma exclusiva una fila para todos los usos, incluidas las operaciones de unión, es preferible a una clave comercial.


¡Ganas todos los Internet con el nombre de usuario más atractivo!
Iain Holder

1
Eso es más o menos lo que es un voto negativo: "No estoy de acuerdo con esto".
jcollum

55
La información sobre herramientas de la flecha hacia abajo dice "Esta respuesta no es útil", no "No estoy de acuerdo con esto". Quizás en esta respuesta específica los significados son cercanos, pero generalmente no son los mismos.
tzot

1
Si alguien piensa que su respuesta es incorrecta, entonces (él / ella) también pensará que lleva al interlocutor en la dirección incorrecta (opuesta a la dirección correcta) y, por lo tanto, juzgará que su respuesta es incluso peor que "inútil", justificando en su mente un voto negativo.
Erwin Smout

1
Sí, las claves sustitutas son una enfermedad. Uno se escapa a la naturaleza y lo usa como pkey, por lo que ahora necesita su propia clave sustituta. Luego, su llave se filtra en la naturaleza (digamos a través de una url) y la enfermedad se propaga.
Samuel Danielson

25

Odio las claves sustitutas en general. Solo deben usarse cuando no hay una clave natural de calidad disponible. Es bastante absurdo cuando lo piensas, pensar que agregar datos sin sentido a tu tabla podría mejorar las cosas.

Aquí están mis razones:

  1. Cuando se usan claves naturales, las tablas se agrupan de la forma en que se buscan con mayor frecuencia, lo que hace que las consultas sean más rápidas.

  2. Cuando utilice claves sustitutas, debe agregar índices únicos en columnas de claves lógicas. Aún necesita evitar datos lógicos duplicados. Por ejemplo, no puede permitir que dos Organizaciones con el mismo nombre en su tabla de Organización aunque el pk sea una columna de identificación sustituta.

  3. Cuando se utilizan claves sustitutas como clave principal, queda mucho menos claro cuáles son las claves primarias naturales. Al desarrollar, desea saber qué conjunto de columnas hace que la tabla sea única.

  4. En una a muchas cadenas de relación, las cadenas de claves lógicas. Entonces, por ejemplo, las organizaciones tienen muchas cuentas y las cuentas tienen muchas facturas. Entonces, la clave lógica de Organización es OrgName. La clave lógica de las cuentas es OrgName, AccountID. La clave lógica de la factura es OrgName, AccountID, InvoiceNumber.

    Cuando se utilizan claves sustitutas, las cadenas de claves se truncan al tener solo una clave externa para el elemento primario inmediato. Por ejemplo, la tabla Factura no tiene una columna OrgName. Solo tiene una columna para AccountID. Si desea buscar facturas para una organización determinada, deberá unirse a las tablas Organización, Cuenta y Factura. Si utiliza claves lógicas, puede consultar la tabla de Organización directamente.

  5. El almacenamiento de valores clave sustitutos de las tablas de búsqueda hace que las tablas se llenen con enteros sin sentido. Para ver los datos, se deben crear vistas complejas que se unan a todas las tablas de búsqueda. Una tabla de búsqueda está destinada a contener un conjunto de valores aceptables para una columna. No debe codificarse almacenando una clave sustituta entera en su lugar. No hay nada en las reglas de normalización que sugiera que debe almacenar un entero sustituto en lugar del valor en sí.

  6. Tengo tres libros de bases de datos diferentes. Ninguno de ellos muestra el uso de claves sustitutas.


77
Odio las claves sustitutas, excepto cuando son necesarias. Son necesarios cuando la empresa utiliza una clave natural que está sujeta a muchos errores y no está dispuesta a tolerar una base de datos afectada por esos errores.
Walter Mitty

26
-1: He escrito y mantenido docenas de aplicaciones. Los que tenían más problemas relacionados con los datos fueron los que usaban claves naturales.
Falcon el

66
Algunos de sus puntos suponen que la clave sustituta debe ser la PK o la columna agrupada, lo cual no es cierto. Sus puntos 1 y 5 ignoran el hecho de que los enteros son 4 bytes y las claves naturales son casi siempre muchos, muchos más bytes. Y, cada índice no agrupado debe repetir los bytes de esas claves naturales que están en el índice agrupado, por lo que las tablas e índices en su base de datos de claves naturales tendrán muchísimas menos filas por página, lo que se traduce en un rendimiento de lectura mucho peor , lo que hace que las consultas sean más lentas , no más rápidas.
ErikE

3
Otra razón contra las claves naturales (ejemplos: números atómicos, VIN, etc.), la lógica de negocios puede cambiar y aumentar el tipo de datos. Por ejemplo: Antes: Seguimiento de cargas de átomos, Después: Seguimiento de cargas de átomos y compuestos. Antes: Seguimiento de vehículos motorizados para capacidad de carga. Después: Agregar aviones, botes, bicicletas y personas para la capacidad de carga.
forforf

3
Supongo que no tiene ninguna tabla en la que la clave primaria esté compuesta, incluso parcialmente, de 1) cualquier atributo que pueda cambiar, o 2) de la entrada del usuario (por ejemplo, listas de búsqueda generadas dinámicamente). Si no puede garantizar la inmutabilidad de la clave, tendrá que actualizar todas estas relaciones de entidad por código o por scripts de "arreglo" manuales. Si nunca tuvo que hacer eso ... Supongo que su base de datos es sustituta sin clave y ... inusual.
code4life

18

Quiero compartir mi experiencia con ustedes en esta guerra interminable: D sobre el dilema de la clave natural vs sustituto. Creo que tanto las claves sustitutas (artificiales generadas automáticamente) como las claves naturales (compuestas de columna (s) con significado de dominio) tienen pros y contras . Entonces, dependiendo de su situación, podría ser más relevante elegir un método u otro.

Como parece que muchas personas presentan las claves sustitutas como la solución casi perfecta y las claves naturales como la peste, me centraré en los argumentos del otro punto de vista:

Desventajas de las claves sustitutas

Las claves sustitutas son:

  1. Fuente de problemas de rendimiento:
    • Por lo general, se implementan mediante columnas de incremento automático que significan:
      • Un viaje de ida y vuelta a la base de datos cada vez que desee obtener un nuevo Id (sé que esto puede mejorarse utilizando algoritmos de almacenamiento en caché o [seq] hilo similar, pero aún así esos métodos tienen sus propios inconvenientes).
      • Si un día necesita mover sus datos de un esquema a otro (al menos sucede con bastante frecuencia en mi empresa), puede encontrar problemas de colisión de Id. Y sí, sé que puedes usar UUID, ¡pero esas duraciones requieren 32 dígitos hexadecimales! (Si le importa el tamaño de la base de datos, puede ser un problema).
      • Si está utilizando una secuencia para todas sus claves sustitutas, entonces, seguramente, terminará con contención en su base de datos.
  2. Propenso a errores. Una secuencia tiene un límite max_value, por lo que, como desarrollador, debe prestar atención a los siguientes puntos:
    • Debe realizar un ciclo de su secuencia (cuando se alcanza el valor máximo, vuelve a 1,2, ...).
    • Si está utilizando la secuencia como un orden (a lo largo del tiempo) de sus datos, entonces debe manejar el caso del ciclo (la columna con Id 1 podría ser más nueva que la fila con Id max-value - 1).
    • Asegúrese de que su código (e incluso sus interfaces de cliente que no deberían suceder como se supone que es un Id interno) admite enteros 32b / 64b que utilizó para almacenar sus valores de secuencia.
  3. No garantizan datos no duplicados. Siempre puede tener 2 filas con los mismos valores de columna pero con un valor generado diferente. Para mí, este es EL problema de las claves sustitutas desde el punto de vista del diseño de la base de datos.
  4. Más en Wikipedia ...

Mitos sobre las claves naturales.

  1. Las claves compuestas son menos ineficientes que las claves sustitutas. ¡No! Depende del motor de base de datos utilizado:
  2. Las claves naturales no existen en la vida real. Lo siento pero existen! En la industria de la aviación, por ejemplo, la siguiente tupla siempre será única con respecto a un vuelo programado dado (aerolínea, fecha de salida, número de vuelo, operacionalSuffix). En términos más generales, cuando se garantiza que un conjunto de datos comerciales sea único por un estándar dado , entonces este conjunto de datos es un candidato clave [bueno] natural.
  3. Las claves naturales "contaminan el esquema" de las tablas secundarias. Para mí esto es más un sentimiento que un problema real. Tener una clave principal de 4 columnas de 2 bytes cada una podría ser más eficiente que una sola columna de 11 bytes. Además, las 4 columnas se pueden usar para consultar la tabla secundaria directamente (usando las 4 columnas en una cláusula where) sin unirse a la tabla primaria.

Conclusión

Use claves naturales cuando sea relevante hacerlo y use claves sustitutas cuando sea mejor usarlas.

¡Espero que esto haya ayudado a alguien!


3
¿Qué sucede cuando se reprograma la fecha de salida del vuelo programado? ¿Tiene que rastrear todas las entidades relacionadas y eliminar las claves, o realmente actualiza todas las claves en las entidades relacionadas? ¿O se trata de una tabla simple y singular (posiblemente ni siquiera 3NF)?
code4life

Excelente punto @ code4life
forcewill

@ code4life: Ahí es donde interviene el operativoSuffix. Para mantener el mismo número de vuelo para evitar la confusión del cliente, agregamos solo un sufijo (es decir, 'D', por ejemplo).
mwnsiri

"Siempre puede tener 2 filas con todos los mismos valores de columna pero con un valor generado diferente", por lo tanto, simplemente coloque una restricción única o compuesta única en sus columnas.
sea

15

Utilice siempre una clave que no tenga sentido comercial. Es solo una buena práctica.

EDITAR: estaba tratando de encontrar un enlace en línea, pero no pude. Sin embargo, en 'Patterns of Enterprise Archtecture' [Fowler] tiene una buena explicación de por qué no debe usar otra cosa que no sea una clave sin otro significado que no sea la clave. Se reduce al hecho de que debería tener un trabajo y un solo trabajo.


22
Martin Fowler puede ser muchas cosas, pero no es una autoridad en el diseño de bases de datos.
Tony Andrews

Creo que deberías proporcionar algún razonamiento antes de llegar a la conclusión.
Arne Evertsson

44
@ArneEvertsoon La razón está ahí. "Se reduce al hecho de que debería tener un trabajo y un solo trabajo". Única responsabilidad.
Iain Holder

10

Las claves sustitutas son bastante útiles si planea utilizar una herramienta ORM para manejar / generar sus clases de datos. Si bien puede usar teclas compuestas con algunos de los mapeadores más avanzados (léase: hibernar), agrega cierta complejidad a su código.

(Por supuesto, los puristas de bases de datos argumentarán que incluso la noción de una clave sustituta es una abominación).

Soy fanático de usar uids para claves sustitutas cuando sea adecuado. La mayor victoria con ellos es que conoce la clave de antemano, por ejemplo, puede crear una instancia de una clase con la ID ya establecida y garantizada para ser única, mientras que, por ejemplo, con una clave entera, necesitará un valor predeterminado de 0 o - 1 y actualice a un valor apropiado cuando guarde / actualice.

Sin embargo, los UID tienen penalizaciones en términos de búsqueda y velocidad de unión, por lo que depende de la aplicación en cuestión si son deseables.


6

Usar una clave sustituta es mejor en mi opinión, ya que no hay ninguna posibilidad de que cambie. Casi cualquier cosa que se me ocurra que pueda usar como clave natural podría cambiar (descargo de responsabilidad: no siempre es cierto, pero comúnmente).

Un ejemplo podría ser una base de datos de automóviles: a primera vista, podría pensar que la placa podría usarse como la clave. Pero esto podría cambiarse, así que sería una mala idea. Realmente no querrás descubrirlo después de lanzar la aplicación, cuando alguien se acerque a ti y quieras saber por qué no pueden cambiar su número de matrícula por uno nuevo y brillante.


1
Lamentablemente, los automóviles tienen una clave natural que no cambia: el VIN (al menos en Estados Unidos ...)
jcollum

@jcollum Sí, sí, ese es un punto justo. Sin embargo, mi opinión sigue en pie, mi ejemplo no fue necesariamente tan bueno como podría ser.
Mark Embling

2
Una lista de idiomas sería un ejemplo para una clave natural, cuando la base en códigos ISO. Entonces, si desea cargar contenido de una tabla en un idioma determinado, no necesitaría unirse a la languagestabla ya que el código de idioma (ID) ya está en la textstabla.
DanMan

@ Danman Tengo que estar de acuerdo contigo allí. Siempre habrá algunos ejemplos que funcionen mejor con una clave natural. Las reglas o los enfoques comunes nunca son absolutos, y ese es un ejemplo al 100% que seguiría con su enfoque :-)
Mark Embling

5

Utilice siempre una sola columna, clave sustituta si es posible. Esto hace que las uniones, así como las inserciones / actualizaciones / eliminaciones sean mucho más limpias porque solo usted es responsable de rastrear una sola información para mantener el registro.

Luego, según sea necesario, apile las claves de su negocio como contrastes o índices únicos. Esto mantendrá su integridad de datos intacta.

La lógica empresarial / las claves naturales pueden cambiar, pero la clave física de una tabla NUNCA debería cambiar.


4

En un escenario de datawarehouse, creo que es mejor seguir el camino clave sustituto. Dos razones:

  • Usted es independiente del sistema fuente y los cambios allí, como un cambio de tipo de datos, no lo afectarán.
  • Su DW necesitará menos espacio físico ya que usará solo tipos de datos enteros para sus claves sustitutas. También sus índices funcionarán mejor.

2

Las claves sustitutas pueden ser útiles cuando la información comercial puede cambiar o ser idéntica. Los nombres comerciales no tienen que ser únicos en todo el país, después de todo. Suponga que trata con dos negocios llamados Smith Electronics, uno en Kansas y otro en Michigan. Puedes distinguirlos por dirección, pero eso cambiará. Incluso el estado puede cambiar; ¿Qué pasa si Smith Electronics de Kansas City, Kansas se mueve al otro lado del río a Kansas City, Missouri? No hay una forma obvia de mantener a estos negocios distintos con información de clave natural, por lo que una clave sustituta es muy útil.

Piense en la clave sustituta como un número ISBN. Por lo general, identifica un libro por título y autor. Sin embargo, tengo dos libros titulados "Pearl Harbor" de HP Willmott, y definitivamente son libros diferentes, no solo ediciones diferentes. En un caso como ese, podría referirme a la apariencia de los libros, o el anterior versus el posterior, pero es mejor que tenga el ISBN para recurrir.


1
Creo que tengo que estar en desacuerdo con tu ejemplo aquí. Un número ISBN es un atributo de un libro. Una clave sustituta es independiente del resto de los datos de la fila, por lo tanto, esta posición recomendaría el uso de una clave sustituta separada para una tabla de libros, a pesar de que el ISBN ya identifica de forma única cada libro.
Christopher Cashell

Alternativamente, piense en el ISBN como una clave sustituta en sí misma. Es un identificador sin significado, solo un código que se aplica a un libro específico. Si está haciendo una tabla de libros, el ISBN también puede ser la clave principal (suponiendo que tenga y siempre tendrá un libro por fila).
David Thornley

@Christopher Cashell - Encontré esta publicación de hace un año, pero pensé agregar algo. No se garantiza que los ISBN sean únicos y pueden tener duplicados. Tengo un amigo que trabajó en una biblioteca durante varios años y a menudo se toparon con libros con ISBN duplicados. El problema es que la singularidad del ISBN incumbe al editor y no a un organismo que garantiza que todos los números de todas las publicaciones son únicos y esos editores no siempre actuaban juntos.
Thomas

2
Encontré esta publicación de hace un año y quería mencionar que los ISBN son, de hecho, claves naturales. Hay un significado integrado en el valor clave en sí mismo, a diferencia de una clave sustituta. Por ejemplo, parte de la clave identifica al editor. Además, como mencioné anteriormente, no se garantiza que sean únicos. Se supone que son únicos, pero esa singularidad proviene de los editores y no siempre fueron perfectos.
Thomas

Técnicamente, las corporaciones no pueden moverse entre estados; lo que sucede es que se crea una nueva corporación en el nuevo estado y se transfieren los activos. Eso también funciona para la información de la base de datos.
Warren Dew

2

Como recordatorio, no es una buena práctica colocar índices agrupados en claves sustitutas aleatorias, es decir, GUID que leen XY8D7-DFD8S, ya que SQL Server no tiene la capacidad de clasificar físicamente estos datos. En su lugar, debe colocar índices únicos en estos datos, aunque también puede ser beneficioso ejecutar simplemente el generador de perfiles SQL para las operaciones de la tabla principal y luego colocar esos datos en el Asesor de ajuste de motor de base de datos.

Ver hilo @ http://social.msdn.microsoft.com/Forums/en-us/sqlgetstarted/thread/27bd9c77-ec31-44f1-ab7f-bd2cb13129be


Estoy bastante seguro de que SQL Server puede ordenar los GUID.
Michael Green

Esto no es exacto, aunque pueden evaluar el GUID, el tipo resultante no tiene sentido para un humano. stackoverflow.com/questions/7810602/…
Bryan Swan

1
Una declaración verdadera, pero bastante diferente a "SQL Server no tiene la capacidad de ordenarlos físicamente".
Michael Green

2

Caso 1: su tabla es una tabla de búsqueda con menos de 50 tipos (insertos)

Use claves comerciales / naturales . Por ejemplo:

Table: JOB with 50 inserts
CODE (primary key)       NAME               DESCRIPTION
PRG                      PROGRAMMER         A programmer is writing code
MNG                      MANAGER            A manager is doing whatever
CLN                      CLEANER            A cleaner cleans
...............
joined with
Table: PEOPLE with 100000 inserts

foreign key JOBCODE in table PEOPLE
looks at
primary key CODE in table JOB

Caso 2: su mesa es una mesa con miles de inserciones

Utilice las claves de sustituto / autoincremento . Por ejemplo:

Table: ASSIGNMENT with 1000000 inserts
joined with
Table: PEOPLE with 100000 inserts

foreign key PEOPLEID in table ASSIGNMENT
looks at
primary key ID in table PEOPLE (autoincrement)

En el primer caso:

  • Puede seleccionar todos los programadores en la tabla PERSONAS sin usar unir con la tabla TRABAJO, pero solo con: "SELECCIONAR * DE PERSONAS DONDE CÓDIGO DE TRABAJO = 'PRG'"

En el segundo caso:

  • Las consultas de su base de datos son más rápidas porque su clave principal es un número entero
  • No necesita preocuparse por encontrar la siguiente clave única porque la base de datos en sí misma le ofrece el próximo aumento automático.

2

Este es uno de esos casos donde una clave sustituta casi siempre tiene sentido. Hay casos en los que elige lo que es mejor para la base de datos o lo que es mejor para su modelo de objetos, pero en ambos casos, usar una clave sin sentido o GUID es una mejor idea. Hace que la indexación sea más fácil y rápida, y es una identidad para su objeto que no cambia.


1

Caballo para cursos. Para decir mi prejuicio; Primero soy desarrollador, así que me preocupa principalmente darles a los usuarios una aplicación que funcione.

He trabajado en sistemas con claves naturales, y tuve que pasar mucho tiempo asegurándome de que los cambios de valor se propagarían.

He trabajado en sistemas con solo claves sustitutas, y el único inconveniente ha sido la falta de datos denormalizados para la partición.

A la mayoría de los desarrolladores tradicionales de PL / SQL con los que he trabajado no les gustaban las claves sustitutas debido a la cantidad de tablas por unión, pero nuestras bases de datos de prueba y producción nunca hicieron sudar; las uniones adicionales no afectaron el rendimiento de la aplicación. Con dialectos de base de datos que no admiten cláusulas como "X unión interna Y en Xa = Yb", o desarrolladores que no usan esa sintaxis, las uniones adicionales para las claves sustitutas hacen que las consultas sean más difíciles de leer y más largas de escribir y escribir. comprobar: ver la publicación de @Tony Andrews. Pero si usa un ORM o cualquier otro marco de generación de SQL, no lo notará. La escritura táctil también mitiga.


También; si realmente quiere conducir a casa que las claves sustitutas son solo eso, comience con un gran número aleatorio e incremente las secuencias en 3+ en lugar de en 1. O use la misma secuencia para generar valores para más de una clave.
WillC

1

Tal vez no sea completamente relevante para este tema, pero es un dolor de cabeza que tengo que lidiar con las claves sustitutas. El análisis pre-entregado de Oracle crea SKs generados automáticamente en todas sus tablas de dimensiones en el almacén, y también almacena los hechos. Por lo tanto, cada vez que (las dimensiones) deben volver a cargarse a medida que se agregan nuevas columnas o deben llenarse para todos los elementos de la dimensión, los SK asignados durante la actualización hacen que los SK no estén sincronizados con los valores originales almacenados en el hecho, lo que obliga una recarga completa de todas las tablas de hechos que se unen a ella. Preferiría que incluso si el SK fuera un número sin sentido, habría alguna forma de que no pudiera cambiar los registros originales / antiguos. Como muchos saben, los productos listos para usar raramente satisfacen las necesidades de una organización, y tenemos que personalizarlos constantemente. Ahora tenemos 3 años de datos en nuestro almacén, y las recargas completas de los sistemas Oracle Financial son muy grandes. Entonces, en mi caso, no se generan a partir de la entrada de datos, sino que se agregan en un almacén para ayudar a informar el rendimiento. Lo entiendo, pero el nuestro cambia, y es una pesadilla.


0

En el caso de la base de datos de punto en el tiempo, es mejor tener una combinación de claves sustitutas y naturales. por ejemplo, necesita rastrear la información de un miembro para un club. Algunos atributos de un miembro nunca cambian. por ejemplo, fecha de nacimiento pero el nombre puede cambiar. Por lo tanto, cree una tabla de miembros con una clave sustituta member_id y tenga una columna para DOB. Cree otra tabla llamada nombre de persona y tenga columnas para member_id, member_fname, member_lname, date_updated. En esta tabla, la clave natural sería member_id + date_updated.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.