Pros y contras de las claves de autoincrement en "todas las tablas"

Question

Estamos teniendo una discusión bastante larga en nuestra compañía acerca de si poner o no una clave de autoincrementación en TODAS las tablas en nuestra base de datos.

Puedo entender poner uno en tablas que tengan una referencia FK, pero no me gusta poner tales claves en todas y cada una de nuestras tablas, aunque las claves nunca se usarían.

Por favor, ayuda con los pros y los contras para poner llaves autoincrement en todas las mesas, aparte de tomar más espacio y ralentizar un poco todo (tenemos algunas tablas con cientos de millones de registros).

Gracias

Answer 1

Supongo que casi todas las tablas tendrán una clave principal, y solo se trata de si esa clave se compone de una o más claves naturales o una sola clave sustituta autoincrementada. Si no está utilizando claves principales, generalmente obtendrá muchas ventajas de usarlas en casi todas las tablas.

Por lo tanto, aquí hay algunos pros & contras de claves sustitutas. En primer lugar, los pros:

• Lo más importante: permiten que las claves naturales cambien. Ejemplo trivial, una tabla de personas debe tener una clave principal de person_id en lugar de last_name, first_name.
• Rendimiento de lectura: los índices muy pequeños son más rápidos de escanear. Sin embargo, esto solo es útil si está limitando su consulta con la clave sustituta. Por lo tanto, es bueno para las tablas de búsqueda, no tan bueno para las tablas principales.
• Simplicidad: si se nombra de forma adecuada, hace que la base de datos sea fácil de usar &.
• Capacidad: si está diseñando algo así como una tabla de hechos del depósito de datos, las claves sustitutas en sus dimensiones le permiten mantener una tabla de hechos muy estrecha, lo que da como resultado una gran mejora de capacidad.

y contras:

• no evitan duplicados de los valores naturales. Por lo tanto, todavía querrá una restricción (índice) única en la clave lógica.
• Escribir rendimiento. Con un índice adicional vas a ralentizar inserciones, actualizaciones y eliminar mucho más.
• Simplicidad: para tablas pequeñas de datos que casi nunca cambian, no son necesarias. Por ejemplo, si necesita una lista de países, puede usar la lista de países ISO. Incluye abreviaturas significativas. Esto es mejor que una clave sustituta porque es pequeña y útil.

En general, las claves sustitutas son útiles, solo tenga en cuenta las desventajas y no dude en utilizar las teclas naturales cuando corresponda.

Answer 2

Si utiliza pequeñas llaves de este tipo de índices agrupados, entonces hay ventajas muy importantes.

igual:

inserciones siempre irá al final de las páginas.

Los índices no agrupados (que necesitan una referencia a la (s) clave (s) CIX) no tendrán direcciones de fila largas para tener en cuenta.

Y más ... Las cosas de Kimberly Tripp son el mejor recurso para esto. Google su ...

Además, si no tiene otra cosa que garantice la exclusividad, tiene un gancho en cada fila que de otro modo no tendría. Debería poner índices únicos en campos que deberían ser únicos y usar FK en los campos apropiados.

Pero ... tenga en cuenta la sobrecarga de crear tales cosas en las tablas existentes. Podría ser bastante aterrador. Puede poner índices únicos en las tablas sin necesidad de crear campos adicionales. Esos índices únicos se pueden usar para FK.

Answer 3

Necesita claves principales en estas tablas. Simplemente no lo sabes todavía.

Answer 4

Agregue claves primarias sustitutas automáticas como parte de la implementación después del diseño lógico para respetar la arquitectura física en disco del motor de base de datos.

Es decir, que tienen propiedades physcial (estrecho, numérico, estrictamente monótona creciente) que el uso de traje como teclas agrupadas, en une etc.

Ejemplo: Si usted está modelando sus datos, a continuación, "producto SKU" es tu llave "Product ID" se agrega después, (con una restricción única en "SKU del producto") al escribir sus instrucciones "CREATE TABLE" porque conoce SQL Server.

Esta es la razón principal.

La otra razón ORM un cerebro muerto que no puede funcionar sin uno ...

Answer 5

Muchas tablas están mejor con una PK compleja, formada por dos o más FKs. Estas tablas corresponden a las relaciones en el modelo Entidad-Relación (ER). El modelo ER es útil para conceptualizar un esquema y comprender los requisitos, pero no debe confundirse con un diseño de base de datos.

Las tablas que representan a las entidades de un modelo ER deben tener un pequeño PK. Utiliza una PK sustituta cuando no se puede confiar en ninguna de las claves naturales. La decisión sobre si una llave puede ser confiable o no es una decisión técnica. Depende de los datos que se le darán y de lo que se espera que haga con ellos.

Si utiliza una clave sustituta que se ha autoincrementado, ahora debe asegurarse de que las referencias duplicadas a la misma entidad no entren en sus bases de datos. Estos duplicados aparecerían como dos o más filas con un PK distinto (porque se ha autoincrementado), pero de lo contrario se duplicarían entre sí.

Si deja duplicados en su base de datos, eventualmente su uso de los datos será un desastre.

Answer 6

Tener claves primarias autoincrementadas puede facilitarle el cambio de capas ORM en el futuro, y no cuesta mucho (suponiendo que conserve sus llaves únicas lógicas).

Answer 7

El enfoque más simple es utilizar siempre claves sustitutas que se autoincrementan mediante el DB o mediante un comando orm. Y en cada mesa Esto se debe a que son el método generalmente más rápido para las uniones y también hacen que el aprendizaje de la base de datos sea extremadamente simple, es decir, nada de esto es la clave para una tabla sin sentido, ya que todos usan el mismo tipo de clave. Sí, pueden ser más lentos pero, en verdad, la parte más importante del diseño es algo que no se romperá con el tiempo. Esto está comprobado para claves sustitutas. Recuerde, el mantenimiento del sistema ocurre mucho más tiempo que el desarrollo. Planifique un sistema que pueda mantenerse. Además, con el hardware actual, la posible pérdida de rendimiento es realmente insignificante.

Answer 8

No soy partidario de las teclas primarias de incremento automático en todas las tablas. Las ideas de que estas te brinden uniones rápidas e inserciones rápidas de filas realmente no son ciertas. Mi compañía llama a este pastel de carne pensar en la historia de la mujer que siempre corta los extremos de su pastel de carne simplemente porque su madre siempre lo hizo. Su madre solo lo hizo porque la sartén era demasiado corta; la tradición continúa aunque la razón ya no exista.

• Cuando la mesa de conducción en una unión tiene una clave de incremento automático, la tabla unida con frecuencia no debería, ya que debe tener el FK a la mesa de conducción. Es el mismo tipo de columna, pero no de autoincremento. Puede usar el FK como PK o como parte de un PK compuesto.

• Agregar una clave de autoincremento a una tabla con una clave naturalmente única no siempre acelerará las cosas, ¿cómo puede hacerlo? Está agregando más trabajo al mantener un índice adicional. Si nunca usa la tecla de incremento automático, esto es un esfuerzo completamente desperdiciado.

• Es muy difícil predecir el rendimiento del optimizador y es imposible predecir el rendimiento futuro. En algunas bases de datos, los índices comprimidos o agrupados disminuirán los costos de las PK naturales. En algunas bases de datos paralelas, las claves de incremento automático se negocian entre nodos y eso aumenta el costo del autoincremento. Solo se puede averiguar mediante la creación de perfiles, y realmente es una lástima tener que cambiar la Política de la Compañía solo para cambiar la forma en que se crea una tabla.

Answer 9

Considera:

se elimina un registro en una tabla que tiene una relación con otra tabla. El registro correspondiente en la segunda tabla no se puede eliminar por razones de auditoría. Este registro queda huérfano de la primera tabla. Si se inserta un nuevo registro en la primera tabla y se utiliza una clave primaria secuencial, este registro ahora está vinculado al huérfano. Obviamente, esto es malo. Al usar un PK incrementado automáticamente, siempre se garantiza una identificación que nunca se haya utilizado antes. Esto significa que los huérfanos permanecen huérfanos, lo cual es correcto.

Nunca usaría teclas naturales como PK. Una PK numérica, como un incremento automático, es la opción ideal la mayoría de las veces, ya que se puede indexar de manera eficiente. Se garantiza que los incrementos automáticos sean únicos, incluso cuando los registros se eliminan, creando relaciones de datos confiables.