sustitutos naturales claves vs/negocio

Question

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

¿Sería mejor que tener una clave de negocio como clave principal, o más bien habría que tener un ID sustituta (es decir, una Identidad de SQL Server) con una restricción única en el campo clave de negocios?

Proporcione ejemplos o pruebas que respalden su teoría.

Answer 1

Ambos. Toma tu pastel y cometelo.

Recuerde que no hay nada especial acerca de una clave principal, 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 exclusividad de acuerdo con las reglas comerciales.

Answer 2

Utilice siempre una clave que no tenga ningún significado comercial. Es solo una buena práctica.

EDIT: 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 nada más que una clave sin otro significado que ser una clave. Todo se reduce al hecho de que debería tener un solo trabajo y un solo trabajo.

Answer 3

La clave sustituta NUNCA tendrá un motivo para cambiar. No puedo decir lo mismo sobre las llaves naturales. Apellidos, correos electrónicos, ISBN nubmers: todos pueden cambiar un día.

Answer 4

En un escenario de datawarehouse, creo que es mejor seguir la ruta clave sustituta. Dos razones:

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

Answer 5

Usar una clave sustituta es mejor, en mi opinión, ya que no hay ninguna posibilidad de que cambie. Casi todo lo que pueda pensar que podría utilizar como una 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 matrícula podría utilizarse como la clave. Pero estos podrían cambiarse, así que sería una mala idea. Realmente no querrá descubrir eso en después de lanzando la aplicación, cuando alguien viene a usted que quiere saber por qué no pueden cambiar su número de matrícula por su nuevo y brillante personalizado.

Answer 6

Las claves sustitutas (típicamente enteros) tienen el valor agregado de hacer que la tabla se relacione más rápido y más económico en almacenamiento y velocidad de actualización (mejor aún, las claves externas no necesitan actualizarse al usar claves sustitutivas, en contraste con campos clave de negocios, que sí cambian de vez en cuando).

La clave principal de una tabla debe usarse para identificar únicamente la fila, principalmente para fines de unión. Piense en una tabla de Personas: los nombres pueden cambiar, y no están garantizados como únicos.

Think Companies: usted es una compañía feliz de Merkin que hace negocios con otras compañías en Merkia. Es lo suficientemente astuto como para no utilizar el nombre de la empresa como clave principal, por lo que utiliza la identificación de empresa única del gobierno de Merkia en su totalidad de 10 caracteres alfanuméricos. Luego Merkia cambia las identificaciones de la compañía porque pensaban 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 empresa de Freedonian tiene hasta 16 caracteres. Necesita ampliar la clave principal de identificación de la compañía (también los campos de clave externa en Pedidos, Problemas, MoneyTransfers, etc.), agregando un campo País en la clave principal (también en las claves externas). ¡Ay! Guerra civil en Freedonia, está dividida en tres países. El nombre del país de su asociado debe cambiarse por el nuevo; actualizaciones en cascada para el rescate.Por cierto, ¿cuál es tu clave principal? (País, CompanyID) o (CompanyID, Country)? Este último ayuda a unirse, el anterior evita otro índice (o tal vez muchos, si desea que sus pedidos se agrupen por país también).

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

Answer 7

sólo algunas razones para el uso de claves suplentes:

1. Estabilidad: Cambiar una clave debido a una necesidad de negocio o natural afectará negativamente a las tablas relacionadas. Las claves sustitutas raramente, si es que alguna vez, deben cambiarse porque no hay un significado relacionado con el valor.

2. Convención: Le permite tener una convención de nombres de columna de clave principal estandarizado en lugar de tener que pensar en cómo unir tablas con diferentes nombres para sus PK.

3. Velocidad: Según el 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.

Answer 8

Este es uno de esos casos en los que una clave sustituta casi siempre tiene sentido. Hay casos en los que elige lo 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 indexar sea más fácil y rápido, y es una identidad para su objeto que no cambia.

Answer 9

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

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

Soy un fan de la utilización de fluidos claves suplentes cuando sea conveniente. La principal victoria con ellos es que conoces la clave por adelantado, p. puede crear una instancia de una clase con la ID ya configurada y garantizada como única, mientras que, por ejemplo, con una clave entera, necesitará establecerse de manera predeterminada en 0 o -1 y actualizar a un valor apropiado cuando guarde/actualice.

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

Answer 10

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

Luego, según sea necesario, apile las llaves de su negocio como restricciones o índices únicos. Esto mantendrá la integridad de los datos intactos.

La lógica de negocios/las teclas naturales pueden cambiar, pero la clave física de una tabla NUNCA debe cambiar.

Answer 11

Parece que nadie ha dicho nada aún en apoyo de las claves no suplentes (dudo en decir "naturales"). Así que aquí va ...

Una desventaja de claves suplentes es que son sentido (citado como una ventaja por algunos, pero ...). Esto a veces lo obliga a unir muchas más tablas en su consulta de lo que realmente debería ser necesario. Compare:

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'; 

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 piensa seriamente la 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é ocurre cuando el código para MYPROJECT o VÁLIDO o cambios de FC? " A lo que mi respuesta sería: "¿por qué querrías necesitar para cambiarlo?" Estas no son claves "naturales" en el sentido de que algún cuerpo externo va a legislar que en lo sucesivo "VÁLIDO" debería volver a codificarse como "BUENO". Solo un pequeño porcentaje de las claves "naturales" pertenece realmente a esa categoría: el número de Seguro Social 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 abogar.

Consulte también: my answer to another question

Answer 12

claves suplentes pueden ser útiles cuando la información empresarial puede cambiar o ser idénticos. Los nombres comerciales no tienen que ser únicos en todo el país, después de todo. Supongamos que tratas con dos empresas llamadas Smith Electronics, una en Kansas y otra en Michigan. Puede distinguirlos por dirección, pero eso cambiará. Incluso el estado puede cambiar; ¿Qué pasa si Smith Electronics de Kansas City, Kansas cruza el río hacia Kansas City, Missouri? No hay una forma obvia de mantener estas empresas diferenciadas con información clave natural, por lo que una clave sustituta es muy útil.

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

Answer 13

En el caso de una base de datos puntual, es mejor tener una combinación de claves indirectas y naturales. p.ej. 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. Así que cree una tabla de miembros con una clave sustituta member_id y tenga una columna para DOB. Cree otra tabla llamada person name y tenga columnas para member_id, member_fname, member_lname, date_updated. En esta tabla, la clave natural sería member_id + date_updated.

Answer 14

Odio las llaves sustitutas en general. Solo deben usarse cuando no hay una clave natural de calidad disponible. Cuando piensas en ello, es bastante absurdo pensar que agregar datos sin sentido a tu mesa podría mejorar las cosas.

Estas son mis razones:

1. Al utilizar las teclas naturales, las tablas se agrupan en la forma en que son más a menudo buscado con lo que las consultas más rápidamente.

2. Al usar claves sustitutivas, debe agregar índices exclusivos en las columnas de claves lógicas. Aún necesita evitar datos duplicados lógicos. Por ejemplo, no puede permitir dos organizaciones con el mismo nombre en su tabla Organización aunque el pk sea una columna de identificación sustituta.

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

4. En una o varias cadenas de relaciones, las cadenas de llaveros lógicas. Entonces, por ejemplo, las Organizaciones tienen muchas Cuentas y Cuentas tienen muchas Facturas. Entonces la clave lógica de la Organización es OrgName. La clave lógica de Cuentas es OrgName, AccountID. La clave lógica de Invoice es OrgName, AccountID, InvoiceNumber.

   Cuando se utilizan claves sustitutivas, las cadenas de teclas 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 usa claves lógicas, puede consultar directamente la tabla Organización.

5. Al almacenar los valores de clave sustitutos de las tablas de búsqueda, las tablas se llenan 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 debería codificarse almacenando una clave sustituta entera en su lugar. No hay nada en las reglas de normalización que sugiera que deba almacenar un número entero sustituto en lugar del valor en sí mismo.

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

Answer 15

Caballo para cursos. Para expresar mi parcialidad; Primero soy desarrollador, por lo que me preocupa principalmente ofrecerles 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 propagaran.

He trabajado en sistemas con solo claves sustitutivas, y el único inconveniente ha sido la falta de datos desnormalizados para la creación de particiones.

La mayoría de los desarrolladores tradicionales de PL/SQL con los que he trabajado no le gustaban las claves sustitutas debido a la cantidad de tablas por combinación, pero nuestras bases de datos de prueba y producción nunca aumentaron; las uniones adicionales no afectaron el rendimiento de la aplicación. Con dialectos de bases de datos que no admiten cláusulas como "X join interno Y en Xa = Yb", o desarrolladores que no usan esa sintaxis, las combinaciones extra para claves sustitutas dificultan la lectura de las consultas, y son más largas para escribir y cheque: vea la publicación de @Tony Andrews. Pero si usa un ORM o cualquier otro marco de generación de SQL, no lo notará. Touch-typing también mitiga.

Answer 16

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

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

Answer 17

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

Uso negocio/teclas 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 insertos

utilizar las teclas de sustituta/autoincrement. 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 las personas de mesa sin el uso de unirse con Job mesa, pero sólo con: "SELECT * FROM gente donde JOBCODE = '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í le proporciona el próximo autoincremento.

Answer 18

Quizás no sea del todo relevante para este tema, pero me duele la cabeza tener que lidiar con claves sustitutivas. Los análisis prealimentados de Oracle crean SKs autogenerados en todas sus tablas de dimensiones en el almacén, y también los almacena en los hechos. Por lo tanto, cada vez que se necesiten cargar (dimensiones) a medida que se agreguen nuevas columnas o que se completen para todos los elementos en la dimensión, las SK asignadas durante la actualización desasocian las SK con los valores originales almacenados en el hecho, forzando 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, hubiera alguna forma de que no pudiera cambiar para los registros originales/antiguos. Como muchos saben, los productos listos para usar rara vez satisfacen las necesidades de una organización, y tenemos que personalizarlos constantemente. Ahora tenemos 3yrs de datos valiosos 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 los nuestros sí cambian, y es una pesadilla.

Answer 19

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

Como parece que muchas personas presentes claves sustitutas como la solución casi perfecta y las teclas naturales como la peste, que se centrarán en el otro punto de los argumentos de vista:

desventajas de claves suplentes

Sustituto claves son:

1. Fuente de los problemas de rendimiento:
   • Por lo general son imp sementó con columnas autoincrementadas que significan:
     • Un viaje de ida y vuelta a la base de datos cada vez que desea obtener un nuevo Id (sé que esto se puede mejorar usando el caché o algoritmos de semejantes al hilo, pero aún aquellos los métodos tienen sus propios inconvenientes).
     • Si un día tiene que mover sus datos de un esquema a otro (sucede con bastante frecuencia en mi empresa al menos) entonces puede encontrar problemas de colisión de Id. Y sí, sé que puede usar UUID, pero esos últimos 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 sustitutivas, seguro - terminará conteniendo en su base de datos.
2. propenso a errores. Una secuencia tiene un límite de max_value por lo que, como desarrollador, debe prestar atención a los siguientes puntos:
   • Debe ciclar su secuencia (cuando se alcanza el valor máximo vuelve a 1,2, .. .).
   • Si está usando la secuencia como un pedido (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úrate de que tu código (e incluso las interfaces de tu cliente, que no deberían ocurrir, ya que se supone que es un Id interno) admite enteros 32b/64b que utilizaste para almacenar tus valores de secuencia.
3. No garantizan la no duplicación de datos. Siempre puede tener 2 filas con todos los mismos valores de columna pero con un valor generado diferente. Para mí esto es EL problema de claves sustitutas desde el punto de vista del diseño de una base de datos.
4. More in Wikipedia...

mitos sobre las teclas naturales

1. claves compuestas son menos ineficiente que las claves sustitutas. ¡No! Depende del motor de base de datos utilizada:
   • Oracle
   • MySQL
2. teclas naturales no existen en la vida real. Lo siento, pero existen! En la industria aeronáutica, por ejemplo, la siguiente tupla será siempre única con respecto a un vuelo programado (línea aérea, fecha de partida, número de vuelo, operacionalSuffix).De manera más general, cuando se garantiza que un conjunto de datos comerciales es exclusivo para una norma dada , este conjunto de datos es un [buen] candidato clave 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 primaria de 4 columnas de 2 bytes cada uno podría ser más eficiente que una sola columna de 11 bytes. Además, las 4 columnas se pueden usar para consultar directamente la tabla secundaria (usando las 4 columnas en una cláusula where) sin unirse a la tabla padre.

Conclusión

Use las teclas naturales cuando sea relevante para hacerlo y utilizar claves suplentes cuando es mejor usarlos.

Espero que esto ayudó a alguien!