Al diseñar tablas, desarrollé el hábito de tener una columna que sea única y que sea la clave principal. Esto se logra de tres maneras según los requisitos:

1. Columna entera de identidad que se incrementa automáticamente.
2. Identificador único (GUID)
3. Una columna de caracteres cortos (x) o enteros (u otro tipo numérico relativamente pequeño) que puede servir como una columna de identificador de fila

El número 3 se usaría para búsquedas bastante pequeñas, principalmente tablas de lectura que podrían tener un código de cadena de longitud estática único o un valor numérico como un año u otro número.

En su mayor parte, todas las demás tablas tendrán un número entero de incremento automático o una clave primaria de identificador único.

La pregunta :-)

Recientemente comencé a trabajar con bases de datos que no tienen un identificador de fila coherente y las claves principales se agrupan actualmente en varias columnas. Algunos ejemplos:

• fecha / hora
• datetime / integer
• datetime / varchar
• char / nvarchar / nvarchar

¿Hay un caso válido para esto? Siempre habría definido una identidad o una columna de identificador único para estos casos.

Además, hay muchas tablas sin claves primarias en absoluto. ¿Cuáles son las razones válidas, si las hay, para esto?

Estoy tratando de entender por qué las tablas se diseñaron tal como estaban, y parece ser un gran desastre para mí, pero tal vez haya buenas razones para ello.

Una tercera pregunta para ayudarme a descifrar las respuestas: en los casos en que se utilizan varias columnas para comprender la clave primaria compuesta, ¿hay alguna ventaja específica para este método frente a una clave sustituta / artificial? Estoy pensando principalmente en lo que respecta al rendimiento, mantenimiento, administración, etc.

Sigo algunas reglas:

1. Las claves primarias deben ser tan pequeñas como sea necesario. Prefiere un tipo numérico porque los tipos numéricos se almacenan en un formato mucho más compacto que los formatos de caracteres. Esto se debe a que la mayoría de las claves primarias serán claves foráneas en otra tabla y se usarán en múltiples índices. Cuanto más pequeña sea su clave, más pequeño será el índice, menos páginas en el caché usará.
2. Las claves primarias nunca deberían cambiar. Actualizar una clave primaria siempre debe estar fuera de discusión. Esto se debe a que es más probable que se use en múltiples índices y se use como una clave foránea. La actualización de una sola clave primaria podría causar el efecto dominó de los cambios.
3. NO use "su clave primaria problemática" como clave primaria de su modelo lógico. Por ejemplo, el número de pasaporte, el número de seguro social o el número de contrato del empleado, ya que estas "claves principales" pueden cambiar para situaciones del mundo real.

En clave sustituta vs natural, me refiero a las reglas anteriores. Si la clave natural es pequeña y nunca cambia, puede usarse como clave principal. Si la clave natural es grande o es probable que cambie, uso claves sustitutas. Si no hay una clave principal, sigo haciendo una clave sustituta porque la experiencia muestra que siempre agregará tablas a su esquema y desearía que pusiera una clave principal en su lugar.

Los versos naturales de las claves artificiales es una especie de debate religioso entre la comunidad de bases de datos. Vea este artículo y otros a los que se vincula. No estoy a favor de tener siempre llaves artificiales, ni de nunca tenerlas. Decidiría caso por caso, por ejemplo:

• Estados de EE. UU .: elegiría state_code ('TX' para Texas, etc.), en lugar de state_id = 1 para Texas
• Empleados: por lo general, creo un id_empleado artificial, porque es difícil encontrar algo más que funcione. El SSN o equivalente puede funcionar, pero podría haber problemas como un nuevo miembro que aún no ha proporcionado su SSN.
• Historial de salario del empleado: (employee_id, start_date). Yo no crear una employee_salary_history_id artificial. ¿A qué punto serviría (aparte de "consistencia tonta" )

Dondequiera que se usen claves artificiales, siempre debe declarar restricciones únicas en las claves naturales. Por ejemplo, use state_id si es necesario, pero será mejor que declare una restricción única en state_code, de lo contrario, seguramente terminará con:

state_id    state_code   state_name
137         TX           Texas
...         ...          ...
249         TX           Texas

Solo un comentario adicional sobre algo que a menudo se pasa por alto. A veces, no usar una clave sustituta tiene beneficios en las tablas secundarias. Digamos que tenemos un diseño que le permite administrar múltiples compañías dentro de una base de datos (tal vez sea una solución alojada, o lo que sea).

Digamos que tenemos estas tablas y columnas:

Company:
  CompanyId   (primary key)

CostCenter:
  CompanyId   (primary key, foreign key to Company)
  CostCentre  (primary key)

CostElement
  CompanyId   (primary key, foreign key to Company)
  CostElement (primary key)

Invoice:
  InvoiceId    (primary key)
  CompanyId    (primary key, in foreign key to CostCentre, in foreign key to CostElement)
  CostCentre   (in foreign key to CostCentre)
  CostElement  (in foreign key to CostElement)

En caso de que el último bit no tenga sentido, Invoice.CompanyIdforma parte de dos claves externas, una para la tabla CostCentre y otra para la tabla CostElement . La clave principal es ( InvoiceID , CompanyID ).

En este modelo, no es posible fastidiar y hacer referencia a un CostElement de una compañía y a un CostCentre de otra compañía. Si se usara una clave sustituta en las tablas CostElement y CostCentre , lo sería.

Cuantas menos posibilidades de arruinar, mejor.

Evito usar claves naturales por una simple razón: error humano. Aunque los identificadores únicos naturales a menudo están disponibles (SSN, VIN, número de cuenta, etc.), requieren que un humano los ingrese correctamente. Si está utilizando SSN como clave principal, alguien transpone un par de números durante la entrada de datos, y el error no se descubre de inmediato, entonces se enfrenta a cambiar su clave principal.

El programa de la base de datos maneja todas mis claves principales en segundo plano y el usuario nunca las conoce.

No hay problema en hacer su clave principal desde varios campos, esa es una Clave Natural .

Puede usar una columna de identidad (asociada con un índice único en los campos candidatos) para crear una clave sustituta .

Esa es una vieja discusión. Prefiero las claves sustitutas en la mayoría de las situaciones.

Pero no hay excusa para la falta de una llave.

RE: EDITAR

Sí, hay mucha controversia sobre eso: D

No veo ninguna ventaja obvia en las claves naturales, además del hecho de que son la elección natural. Siempre pensarás en Name, SocialNumber , o algo así, en lugar de idPerson .

Las claves sustitutas son la respuesta a algunos de los problemas que tienen las claves naturales (propagación de cambios, por ejemplo).

A medida que te acostumbras a los sustitutos, parece más limpio y manejable.

Pero al final, descubrirás que es solo una cuestión de gustos o mentalidad. La gente "piensa mejor" con claves naturales, y otros no.

Las tablas deben tener una clave primaria todo el tiempo. Cuando no es así, debería haber sido un campo AutoIncrement.

En ocasiones, las personas omiten la clave principal porque transfieren una gran cantidad de datos y puede ralentizar (dependiendo de la base de datos) el proceso. PERO, debe agregarse después.

Algún comentario sobre la tabla de enlaces , esto es correcto, es una excepción, PERO los campos deben ser FK para mantener la integridad, y en algunos casos esos campos también pueden ser claves primarias si no se autoriza la duplicación de enlaces ... pero para mantenerlos en un forma simple porque la excepción es algo frecuente en la programación, la clave primaria debe estar presente para mantener la integridad de sus datos.

Además de todas esas buenas respuestas, solo quiero compartir un buen artículo que acabo de leer, El gran debate clave principal .

Solo para citar algunos puntos:

El desarrollador debe aplicar algunas reglas al elegir una clave principal para cada tabla:

• La clave primaria debe identificar de forma exclusiva cada registro.
• El valor de clave principal de un registro no puede ser nulo.
• El valor-clave principal debe existir cuando se crea el registro.
• La clave principal debe permanecer estable; no puede cambiar los campos de clave principal.
• La clave primaria debe ser compacta y contener la menor cantidad posible de atributos.
• El valor de la clave primaria no se puede cambiar.

Las claves naturales (tienden a) romper las reglas. Las claves sustitutas cumplen con las reglas. (Será mejor que leas ese artículo, ¡vale la pena!)

¿Qué tiene de especial la clave primaria?

¿Cuál es el propósito de una tabla en un esquema? ¿Cuál es el propósito de una clave de una tabla? ¿Qué tiene de especial la clave primaria? Las discusiones sobre las claves primarias parecen perder el punto de que la clave primaria es parte de una tabla, y esa tabla es parte de un esquema. Lo que es mejor para la tabla y las relaciones de la tabla debe conducir la clave que se utiliza.

Las tablas (y las relaciones entre tablas) contienen datos sobre la información que desea registrar. Estos hechos deben ser independientes, significativos, fáciles de entender y no contradictorios. Desde una perspectiva de diseño, otras tablas agregadas o eliminadas de un esquema no deberían afectar la tabla en cuestión. Debe haber un propósito para almacenar los datos relacionados solo con la información misma. Comprender lo que se almacena en una tabla no debería requerir someterse a un proyecto de investigación científica. Ningún hecho almacenado para el mismo propósito debe almacenarse más de una vez. Las claves son una parte o la totalidad de la información que se registra, que es única, y la clave principal es la clave especialmente designada que será el punto de acceso principal a la tabla (es decir, debe elegirse por la consistencia y el uso de los datos, no solo insertar actuación).

• Aparte: El desafortunado efecto secundario de la mayoría de las bases de datos diseñadas y desarrolladas por los programadores de aplicaciones (que a veces soy) es que lo mejor para la aplicación o el marco de la aplicación a menudo impulsa la elección de la clave principal para las tablas. Esto conduce a claves enteras y GUID (ya que son fáciles de usar para marcos de aplicaciones) y diseños de tablas monolíticas (ya que reducen el número de objetos de marco de aplicaciones necesarios para representar los datos en la memoria). Estas decisiones de diseño de bases de datos basadas en aplicaciones conducen a problemas significativos de consistencia de datos cuando se usan a escala. Los marcos de aplicación diseñados de esta manera conducen naturalmente a diseños de tabla a la vez. Los "registros parciales" se crean en tablas y datos completados con el tiempo. Se evita la interacción de varias tablas o cuando se usa causa datos inconsistentes cuando la aplicación funciona incorrectamente. Estos diseños conducen a datos sin sentido (o difíciles de entender), datos distribuidos en tablas (debe mirar otras tablas para tener sentido de la tabla actual) y datos duplicados.

Se dijo que las claves primarias deberían ser tan pequeñas como sea necesario. Diría que las claves deberían ser tan grandes como sea necesario. Se debe evitar agregar aleatoriamente campos sin sentido a una tabla. Es aún peor crear una clave a partir de un campo sin sentido agregado al azar, especialmente cuando destruye la dependencia de unión de otra tabla a la clave no primaria. Esto solo es razonable si no hay buenas claves candidatas en la tabla, pero este hecho seguramente es un signo de un diseño de esquema deficiente si se usa para todas las tablas.

También se dijo que las claves primarias nunca deberían cambiar, ya que la actualización de una clave primaria siempre debe estar fuera de discusión. Pero la actualización es lo mismo que eliminar seguido de insertar. Según esta lógica, nunca debe eliminar un registro de una tabla con una clave y luego agregar otro registro con una segunda clave. Agregar la clave primaria sustituta no elimina el hecho de que exista la otra clave en la tabla. La actualización de una clave no primaria de una tabla puede destruir el significado de los datos si otras tablas dependen de ese significado a través de una clave sustituta (por ejemplo, una tabla de estado con una clave sustituta que tiene la descripción del estado cambiada de 'Procesado' a 'Cancelado' 'definitivamente corrompería los datos). Lo que siempre debe estar fuera de discusión es destruir el significado de los datos.

Dicho esto, estoy agradecido por las muchas bases de datos mal diseñadas que existen en las empresas de hoy (gigantes sin sentido-sustitutos-datos-corruptos-1NF), porque eso significa que hay una cantidad interminable de trabajo para las personas que entienden el diseño adecuado de la base de datos . Pero, por el lado triste, a veces me hace sentir como Sísifo, pero apuesto a que tenía 401k (antes del accidente). Manténgase alejado de blogs y sitios web para preguntas importantes de diseño de bases de datos. Si está diseñando bases de datos, busque CJ Date. También puede hacer referencia a Celko para SQL Server, pero solo si se tapa la nariz primero. En el lado de Oracle, haga referencia a Tom Kyte.

Una clave natural, si está disponible, suele ser la mejor. Entonces, si datetime / char únicamente identifica de la fila y ambas partes son significativas para la fila, eso es genial.

Si solo la fecha y hora es significativa, y se agrega el carácter para que sea único, entonces también podría ir con un campo de identificación.

Aquí está mi propia regla de oro que he establecido después de más de 25 años de experiencia en desarrollo.

• Todas las tablas deben tener una clave principal de columna única que se incremente automáticamente.
• Inclúyalo en cualquier vista que sea actualizable
• La clave primaria no debe tener ningún significado en el contexto de su aplicación. Esto significa que no debe ser un SKU, o un número de cuenta o una identificación de empleado o cualquier otra información que sea significativa para su aplicación. Es simplemente una clave única asociada con una entidad.

La base de datos utiliza la clave principal para fines de optimización y su aplicación no debe usarla para nada más que identificar una entidad en particular o relacionarse con una entidad en particular.

Tener siempre una clave primaria de valor único hace que la ejecución de UPSERT sea muy sencilla.

Utilice índices adicionales para admitir claves de varias columnas que tengan significado en su aplicación.

Para mí, las claves naturales versus las artificiales son una cuestión de cuánta lógica empresarial desea en su base de datos. Número de seguridad social (SSN) es un gran ejemplo.

"Cada cliente en mi base de datos tendrá y debe tener un SSN". Bam, listo, conviértalo en la clave principal y termine con él. Solo recuerde cuando su regla de negocio cambia, usted se quema.

No me gustan las claves naturales, debido a mi experiencia con el cambio de las reglas comerciales. Pero si está seguro de que no cambiará, podría evitar algunas uniones críticas.

Sospecho que la terapia de periódico enrollada de Steven A. Lowe es necesaria para el diseñador de la estructura de datos original.

Por otro lado, los GUID como clave principal pueden ser un gran rendimiento. No lo recomendaría

Debe usar una clave primaria 'compuesta' o 'compuesta' que consta de múltiples campos.

Esta es una solución perfectamente aceptable, vaya aquí para obtener más información :)

Yo también siempre uso una columna de identificación numérica. En Oracle uso el número (18,0) sin ninguna razón real por encima del número (12,0) (o lo que sea un int en lugar de un largo), tal vez simplemente no quiero preocuparme por obtener unos pocos miles de millones de filas en el db!

También incluyo una columna creada y modificada (marca de tiempo de tipo) para el seguimiento básico, donde parece útil.

No me importa establecer restricciones únicas en otras combinaciones de columnas, pero realmente me gusta mi id, creado, requisitos de línea base modificados.

Busco claves primarias naturales y las uso donde puedo.

Si no se pueden encontrar claves naturales, prefiero un GUID a un INT ++ porque SQL Server usa árboles, y es malo agregar siempre claves al final en los árboles.

En las tablas que son acoplamientos de muchos a muchos, uso una clave primaria compuesta de las claves externas.

Debido a que tengo la suerte de usar SQL Server, puedo estudiar planes de ejecución y estadísticas con el generador de perfiles y el analizador de consultas y descubrir cómo funcionan mis claves muy fácilmente.

Siempre uso un campo de identidad o autonumeración.

Trabajé para un cliente que había usado SSN como clave principal y luego, debido a las regulaciones de HIPAA, me vi obligado a cambiar a un "MemberID" y causó muchos problemas al actualizar las claves externas en las tablas relacionadas. Cumplir con un estándar consistente de una columna de identidad me ha ayudado a evitar un problema similar en todos mis proyectos.

Todas las mesas deberían tener una clave primaria. De lo contrario, lo que tiene es un HEAP; esto, en algunas situaciones, podría ser lo que desea (gran carga de inserción cuando los datos se replican a través de un intermediario de servicios a otra base de datos o tabla, por ejemplo).

Para las tablas de búsqueda con un bajo volumen de filas, puede usar un código 3 CHAR como clave principal, ya que esto ocupa menos espacio que un INT, pero la diferencia de rendimiento es insignificante. Aparte de eso, siempre usaría un INT a menos que tenga una tabla de referencia que tal vez tenga una clave primaria compuesta hecha de claves externas de tablas asociadas.

Si realmente desea leer todo el proceso de ida y vuelta en este antiguo debate, busque la "clave natural" en Stack Overflow. Debería volver páginas de resultados.

GUID se pueden usar como clave principal, pero debe crear el tipo correcto de GUID para que funcione bien.

Necesita generar GUID COMB. Un buen artículo al respecto y las estadísticas de rendimiento es El costo de los GUID como claves principales .

También parte del código para crear GUID COMB en SQL está en Uniqueidentifier vs identity ( archivo ) .

Hacemos muchas uniones y las claves primarias compuestas se han convertido en un gran rendimiento. Un int simple o largo se ocupa de muchos problemas a pesar de que está introduciendo una segunda clave candidata, pero es mucho más fácil y más comprensible unirse en un campo frente a tres.

Seré sincero acerca de mi preferencia por las claves naturales: úselas cuando sea posible, ya que le facilitarán mucho la administración de la base de datos. Establecí un estándar en nuestra empresa de que todas las tablas tienen las siguientes columnas:

• ID de fila (GUID)
• Creador (cadena; tiene un valor predeterminado del nombre del usuario actual (SUSER_SNAME() en T-SQL))
• Creado (fecha y hora)
• Marca de tiempo

El ID de fila tiene una clave única por tabla y, en cualquier caso, se genera automáticamente por fila (y los permisos evitan que cualquiera lo edite), y se garantiza razonablemente que sea único en todas las tablas y bases de datos. Si algún sistema ORM necesita una única clave de ID, esta es la que debe usar.

Mientras tanto, la PK real es, si es posible, una clave natural. Mis reglas internas son algo como:

• Personas: utilice la clave sustituta, por ejemplo, INT. Si es interno, el GUID de usuario de Active Directory es una opción aceptable
• Tablas de búsqueda (por ejemplo, códigos de estado): use un código CHAR breve; es más fácil de recordar que los INT, y en muchos casos los formularios en papel y los usuarios también lo usarán por brevedad (por ejemplo, Estado = "E" para "Caducado", "A" para "Aprobado", "NADIS" para "No se detectó asbesto" En la muestra")
• Vinculación de tablas: combinación de FK (por ejemplo EventId, AttendeeId)

Así que, idealmente, terminas con un PK natural, legible y memorable para los humanos, y un GUID de una ID por tabla compatible con ORM.

Advertencia: las bases de datos que mantengo tienden a los 100.000 registros en lugar de millones o miles de millones, así que si tienes experiencia en sistemas más grandes que contraindican mi consejo, ¡no dudes en ignorarme!