¿Cuál es la mejor práctica para las claves primarias en las tablas?


256

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.


Encontré que las Habilidades de base de datos: un enfoque sensato para elegir las claves principales son una buena lectura y sigo la mayoría de los puntos descritos.
usuario2864740

Respuestas:


254

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.


3
¡Me gusta! ¿Tiene alguna documentación para sus "reglas"? ¡Gracias!
Lloyd Cotten

44
No, solo experiencia. Cuando se trata de bases de datos "pequeñas", estas cosas no importan demasiado. Pero cuando tratas con db grandes, todas las pequeñas cosas importan. Imagínese si tiene mil millones de filas con int o long pk en comparación con el uso de texto o guid. ¡Hay una gran diferencia!
Logicalmind

44
Solo recuerde poner ese índice único en la clave natural (si es que existe, lo que a menudo no es el caso) cuando utiliza una clave artificial.
HLGEM

3
@Lloyd Cotten: Esto es lo que dice un proveedor de motores de big data en apoyo de la regla número 1: skyfoundry.com/forum/topic/24 . Me convenció para volver a Ints
Placas

44
incluso si "sabe" que "la clave natural es pequeña y nunca cambiará", piénselo dos veces. "nunca reutilizamos esos códigos" son las últimas palabras famosas ... Las únicas cosas que entran en las categorías de pequeños, que nunca cambian son las normas iso y otras (códigos de país, códigos de aeropuerto de iata,). Cosas como "cuál es la representación de 2 letras para esta marca interna" ... piénselo dos veces antes de asumir que "eso" nunca cambiará, es una decisión financiera lejos de la reconstrucción de una base de datos.
Andrew Hill

90

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

99
En algunos casos con SQL Server 2005/2008 la clave natural (texto) puede ser más rápida que una clave int. Tengo una aplicación con un código amigable de 7-8 caracteres que usamos como clave principal y que fue más rápido (y a menudo más conveniente) que un sustituto int. Necesitábamos el código de todos modos para poder tener un código legible / memorable por humanos que pudiéramos transferir de manera segura sin conflicto a una instancia de aplicación diferente (múltiples sitios que se agregan en un sitio más grande).
lambacck

1
+1 Buena respuesta. Sin embargo, conseguiría que el oficial de personal sea la fuente confiable de un identificador de empleado, es decir, el oficial responsable de verificar a los empleados en la vida real que puedan usar identificadores como SSN, referencias, etc. El departamento de personal debe ser confiable. fuente de identificadores de empleados, no el DBMS!
cuando el

@ un día cuando- no lo haría. confiar en el oficial de personal. La gente se va, llegan nuevos y tienen ideas diferentes. Bríndeles acceso al identificador que piensan que es único / quieren usar, pero internamente para el db, dba debería tomar su propia decisión
Dave Pile

1
Tenga en cuenta que el SSN no es necesariamente único en todos los países. Al menos en Austria, varias personas podrían compartir el mismo número
maja

También en algunos países (creo que incluso en los EE. UU.) En realidad recomiendan no compartir el SSN.
Stijn de Witt

25

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.


66
Esta es una desventaja infra citada cuando se usan claves sustitutas. Si la tabla tiene una clave sustituta, todavía puedo usarla para este tipo de restricciones. Desafortunadamente, aunque la restricción requiere un índice y es extraño crear un índice único en (clave_rogada, otra_columna) cuando (clave_roja) es único en sí mismo. Además, (other_column) a menudo es totalmente redundante en una tabla de mapas ya que (surrogate_key) es única en la tabla extranjera. Los sustitutos realmente pueden arruinar las cosas.
Samuel Danielson

24

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.


1
He trabajado con algunas bases de datos que usaban SSN o ID de impuestos como claves principales. Ineficiente cuando se trata de referencias de almacenamiento y claves externas. Sin mencionar que el SSN de una persona puede cambiar. Así que estoy completamente de acuerdo contigo.
Alex Jorgenson

13

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.


13
La gente "piensa mejor" con claves naturales. Máquinas y bases de datos, no.
FDCastel

11

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.


Estoy de acuerdo. Y en el caso de que se inserte una gran cantidad de datos, elimine la restricción de clave principal (o use INSERT IDENTITY ON en TSQL) y vuelva a colocarla después :)
Andrew Rollings

1
Hay excepciones: obviamente, tablas de enlaces
annakata

Otra razón: si no hay PK / clave única, los navegadores de tablas (quiero decir, algo así como Access / SQL Server Management Studio) se negarán a actualizar / eliminar una sola fila con una fila duplicada. Tendrás que escribir SQL para eso.
Dennis C

Es bastante común omitir un PK de una tabla de hechos del almacén de datos. En Oracle, puede hacer referencia a la pseudocolumna ROWID como un identificador único a corto plazo (es decir, no lo almacene en ningún lugar y espere que no cambie)
David Aldridge

9

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!)


7

¿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.


1
"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". - Hay un caso para esto, y eso es efectivamente lo que hará una cláusula "ON DELETE RESTRICT" en una clave externa. En algunos casos (por ejemplo, cuando se requiere un seguimiento de auditoría), un campo booleano "eliminado" sería mejor que permitir que se elimine el registro.
Waz

6

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.


99
Por lo general mejor? No tengo ninguna base científica, pero estoy casi seguro de que la mayoría de las personas prefieren una clave sustituta sobre la natural. En muchos casos no hay clave natural.
JC.

3
SIEMPRE debe haber una clave natural para cualquier fila en su base de datos. Esa clave "natural" puede ser algo generado en el mundo de los negocios o por su sistema técnico, pero siempre debe existir.
Tom H

2
Si, en su mundo, esa es la única forma de identificar una fila en la tabla, entonces sí. Por supuesto, cuando un diseñador elige crear un GUID para un PK, generalmente es porque no ha hecho el trabajo para encontrar la clave natural REAL, por lo que en ese caso el GUID NO es la clave natural.
Tom H

8
2. Si toma su llave del mundo natural, el mundo natural cambiará para romper su llave. Si usa el número de teléfono, obtendrá dos usuarios del mismo hogar. Si usa el apellido, se casan. Si usa el SSN, las leyes de privacidad cambiarán y requerirán que las elimine.
James Orr

2
@Barry: RE: # 2. Si el mundo natural cambia y eso hace que cambie su clave natural, eso significa que hizo un mal trabajo seleccionando una clave natural. Por definición, una clave natural no cambia con el tiempo.
Tom H

6

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.


5

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.


8
Y he visto datos en los que el SSN no es único, aunque debería serlo. ¡Tenga cuidado con las claves naturales si importa sus datos de otra fuente!
HLGEM

2
Si está sujeto a robo de identidad, puede cambiar su número de seguro social. Hay cuatro situaciones más en las que cambiarán su número y se enumeran en el sitio ssa.gov.
Zvi Twersky

4

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


2
Decir que es un cerdo de rendimiento es una optimización prematura. Se requieren guías en algunos casos (clientes desconectados, fusión futura de tablas, replicación)
JC.

2
¡"Optimización prematura" es una frase utilizada en exceso en SO (en mi humilde opinión)! Sí, es posible que se requieran GUID en ALGUNOS casos, pero Andrew tiene razón al señalar que no deberían usarse como el tipo de datos predeterminado, ya sea necesario o no.
Tony Andrews

OK, en realidad no fue una optimización prematura. Lo que quise decir es que la mayoría de las personas no experimentan el volumen requerido para notar la diferencia de rendimiento. Sí, use autoincrement si sabe que nunca necesitará una guía.
JC.

O usa ambos. Tenga una clave primaria basada en int / long para selecciones rápidas y combinaciones agradables, y luego tenga un campo guid. Al menos, eso es lo que estoy haciendo. ¿Esto esta mal? ¿No debería estar haciendo eso? :)
Andrew Rollings

También estoy usando ambas columnas. Pero no estoy seguro si está mal o no. ¿Lo encontraste @AndrewRollings?
YÒGÎ

3

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 :)


3

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.


2
También debo señalar que no pongo ID en las tablas de enlace / unión, solo en las tablas que contienen datos.
JeeBee

3

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.


¿Tiene alguna documentación para respaldar esta afirmación: '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'? No escéptico, solo intento recopilar documentación.
Lloyd Cotten

1
@Lloyd: Me alegra que te estés interesando en algo que me parece muy fascinante. Un buen punto de partida en msdn.microsoft.com/en-us/library/ms177443(SQL.90).aspx
Guge

2

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.


66
La mala selección de una clave natural por parte de un desarrollador no significa que las claves naturales sean malas.
Tom H

1
¿Una herramienta que es difícil de usar de alguna manera no es un punto en contra de esa herramienta?
Sqeaky

1

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.


1

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.


1

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 ) .


55
En mi humilde opinión, los guid solo deberían usarse cuando necesites sincronizar datos entre bases de datos. En el que una identificación generada automáticamente es problemática. La diferencia entre usar un guid y usar un tipo numérico básico es que un guid requerirá 16 bytes por fila, mientras que un numérico será mucho más pequeño.
Logicalmind

Si va al enlace que proporcioné anteriormente, hay muy poca diferencia en el rendimiento con las Guías COMB.
Donny V.

0

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.


1
Esta estrategia se desmorona cuando ahora tiene que atravesar 6 tablas para unir las dos tablas reales que necesita porque las claves compuestas no se propagaron. También termina requiriendo el uso de bucles / cursores para múltiples inserciones que pueden ser un ENORME rendimiento.
Tom H

2
No soy demasiado grande para aprender algo nuevo. Me encantaría ver un ejemplo de lo que estás diciendo, sería útil inyectar un pequeño hecho racional en algunos de estos argumentos religiosos.
Dan Blair,

0

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!


1
¿Está sugiriendo crear ambos GUID y INT SK para tablas sin clave natural fuerte?

No tiene que hacerlo, pero los beneficios son: a) facilita la replicación si la necesita, b) cuando se trata de ORM, puede asignar una identificación única a su objeto en el código antes de guardarlo (lo cual es útil si usted tiene que hacer muchas ediciones en su objeto, tal vez guardar en un caché de sesión, antes de guardarlo). La clave es el INT en este caso; El GUID es solo una ventaja.
Keith Williams
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.