vertabelo - sqldb design
Cuándo usar una clave primaria autoincrementada y cuándo no? (7)
Estoy tratando de descubrir las "mejores prácticas" para decidir si agregar o no un entero autoincrementado 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?
Con respecto al uso de ISBN y SSN, realmente tiene que pensar en cuántas filas en otras tablas van a hacer referencia a éstas a través de claves externas porque esos identificadores ocuparán mucho más espacio que un entero y, por lo tanto, pueden generar un desperdicio de espacio en disco y posiblemente para empeorar el rendimiento.
El principal problema que he visto con el aumento automático de un enfoque de enteros 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.
El viejo tema lo sé, pero otra cosa a tener en cuenta es que, dado que la mayoría de los RDBMS establecen bloques en el disco usando el PK, usar un PK de incremento automático simplemente aumentará enormemente tu 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 usar una identificación autoincrementada, tal vez considere usarla como parte de un PK. Tack it 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.
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 disponible, 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 en particular es para mi libro, el número de registros de ventas es muy pequeño, por lo que hacer la combinación y leer un registro extra es una gran diferencia porcentual).
Otra ventaja de las claves naturales 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 trates de 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?
Estoy tratando de descubrir las "mejores prácticas" para decidir si agregar o no un entero autoincrementado como la clave principal de una tabla.
Úselo como un identificador único con un conjunto de datos donde el 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?
Tienes la idea allí.
El incremento automático se debe usar 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 tablero de mensajes, 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 usar claves naturales donde sea posible, solo recuerde hacer que el campo sea la clave principal y asegúrese de que esté indexado para el rendimiento