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.

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.

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.

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

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.

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.

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.

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:
   • Oráculo
   • MySQL
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!

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.