Cuándo utilizar una clave principal autoincrementada y cuándo no?

Question

Estoy tratando de descubrir las "mejores prácticas" para decidir si agregar o no un entero de incremento automático como la clave principal de una tabla.

Digamos que tengo una tabla que contiene datos sobre los elementos químicos. El número atómico de cada elemento es único y nunca cambiará. Entonces, en lugar de usar un entero autoincrementado para cada columna, probablemente tendría más sentido usar el número atómico, ¿correcto?

¿Sería lo mismo si tuviera una tabla de libros? ¿Debo usar el ISBN o un entero de incremento automático para la clave principal? ¿O una tabla de empleados que contiene el SSN de cada persona?

Answer 1

Hay muchas preguntas ya abordadas en Stack Overflow que pueden ayudarlo con sus preguntas. Ver here, here, here y here.

El término que debe buscar: surrogated keys.

Espero que ayude.

Answer 2

Tienes la idea allí mismo.

El incremento automático se debe utilizar como una clave única cuando ya no exista una clave única sobre los elementos que está modelando. Por lo tanto, para Elementos, puede usar el Número atómico o Libros, el número ISBN.

Pero si las personas están publicando mensajes en un tablón de mensajes, entonces estos necesitan una identificación única, pero no contienen uno de forma natural, por lo que asignamos el siguiente número de una lista.

tiene sentido utilizar las teclas naturales siempre que sea posible, sólo recuerde que el campo como clave principal y asegurarse de que está indexado para un rendimiento

Answer 3

que estoy tratando de averiguar las "mejores prácticas" para decidir si agregar o no un entero autoincrementado como la clave primaria de una tabla.

Úselo como un identificador único con un conjunto de datos donde PKey no es parte de los datos administrados por el usuario.

Digamos que tengo una tabla que contiene datos sobre los elementos químicos. El número atómico de cada elemento es único y nunca cambiará. Entonces, en lugar de usar un entero autoincrementado para cada columna, probablemente tendría más sentido usar el número atómico, ¿correcto?

Sí.

¿Sería lo mismo si tuviera una tabla de libros? ¿Debo usar el ISBN o un entero de incremento automático para la clave principal? ¿O una tabla de empleados que contiene el SSN de cada persona?

ISBNs/SS # s son asignados por terceros y debido a su gran tamaño de almacenamiento sería una forma muy ineficiente de identificar de manera única una fila. Recuerde, las PKeys son útiles cuando une tablas. ¿Por qué utilizar un formato de datos grande como un ISBN que incluiría numerosos caracteres de texto como el identificador único cuando hay disponible un formato pequeño y compacto como Integer?

Answer 4

El principal problema que he visto con el aumento automático de un enfoque entero es cuando exporta sus datos para llevarlos a otra instancia de db, o incluso una operación de archivo y restauración.Debido a que el número entero no tiene relación con los datos a los que hace referencia, no hay forma de determinar si tiene duplicados al restaurar o agregar datos a una base de datos existente. Si no quiere ninguna relación entre los datos contenidos en la fila y el PK, solo usaría un guid. No es muy fácil de usar, pero resuelve el problema anterior.

Answer 5

Con respecto al uso de ISBN y SSN, realmente tiene que pensar en cuántas filas en otras tablas van a hacer referencia a estas a través de claves externas porque esos identificadores ocuparán mucho más espacio que un entero y por lo tanto pueden conducir a un desperdicio de espacio en disco y posiblemente empeore el rendimiento.

Answer 6

Esta es una pregunta muy debatida, con mucha emoción en ambos lados.

En mi humilde opinión, si hay una buena clave natural utilizable, como un ISBN, la uso. Voy a almacenarlo en la base de datos de todos modos. Sí, una clave natural suele ser más grande que una clave de autoincrecimiento entero, pero creo que este problema es exagerado. El espacio en disco es barato hoy. Me preocuparía más que tardara más en procesarse. Si estuvieras hablando de un campo de texto de 80 bytes como clave principal, diría que no. Pero si estás pensando en usar un ISBN de 10 bytes en lugar de un entero grande de 8 bytes, no me puedo imaginar que eso represente una gran penalización en el rendimiento.

A veces hay una ventaja de rendimiento para las teclas naturales. Supongamos, por ejemplo, que quiero encontrar cuántas copias de un libro dado se han vendido. No me importan los datos del registro maestro del Libro. Si la clave principal es ISBN, simplemente podría escribir "select count (*) from sale where isbn = '143573338X'". Si utilizo una clave de autoincrement, tendría que hacer una combinación para buscar el isbn, y la consulta se vuelve más compleja y más lenta, como "select count (*) de book join sale using (bookid) where isbn = '143573338X' ". (Y puedo asegurarle que como este ISBN particular es para mi libro, el número de registros de venta es muy pequeño, por lo que hacer la unión y leer un registro adicional es una gran diferencia porcentual!)

Otra ventaja de la natural claves es que cuando tiene que trabajar en la base de datos y mira los registros que se refieren a esta tabla por clave, es fácil ver a qué registro se refieren.

Por otro lado, si no hay una buena clave natural obvia, no intente improvisar una loca. He visto a personas intentar hacer una llave natural concatenando juntas las primeras 6 letras del nombre del cliente, su año de nacimiento y su código postal, y luego rezar para que eso sea único. Ese tipo de tontería solo te está causando problemas. A menudo las personas terminan tomando un número de secuencia para asegurar que sea único de todos modos, y en ese punto, ¿para qué molestarse? ¿Por qué no usar solo el número de secuencia como la clave?

Answer 7

Tema anterior Lo sé, pero otra cosa a tener en cuenta es que, dado que la mayoría de los RDBMS establecen bloques en el disco utilizando el PK, usar un PK de incremento automático simplemente aumentará enormemente su contención. Esto puede no ser un problema para la base de datos de su bebé con la que está jugando, pero créanme que puede causar problemas de rendimiento masivo en el extremo más grande de la ciudad.

Si debe utilizar un ID de incremento automático, tal vez considere el uso como parte de un PK. Tachuelo en el extremo para mantener la singularidad .....

Además, es mejor agotar todas las posibilidades de PK naturales antes de saltar a un sustituto. La gente generalmente es floja con esto.