¿Agregar una identificación en cada tabla incluso si no es necesaria?

8

¿Es este diseño bueno o malo agregar, por defecto, el campo de ID en cada tabla de una base de datos, incluso cuando no ve actualmente el uso de esta ID (por ejemplo, en una tabla MxN)?

database-design Pierre Watelet
fuente
si no tiene una columna de identificación, ¿algún otro campo (s) constituirá la clave principal?
Thanos Papathanasiou
Normalmente agrego una ID si probablemente se usan en otra tabla ... ahorraría espacio aunque solo un poco
zfm

Respuestas:

3

En muchos casos, tener una identificación artificial en cada mesa es muy conveniente; en algunos casos, es solo un dolor en el a **.

En general, hago eso en cada proyecto en el que estoy trabajando.

Ventajas:

  • Generalmente es más fácil escribir o generar código de acceso cuando se puede acceder a todas y cada una de las tablas mediante un campo clave llamado ID, tipo Integer.

  • A veces, las claves naturales son volátiles. Por ejemplo, en un sistema de gestión de almacenes ya muy complejo, nos enfrentamos a la tarea de que los códigos de los productos cambien, por ejemplo, lo que ha sido el producto 001234 se conocerá como 002345 en el futuro. Desafortunadamente, ese sistema no usó ID artificiales, sino el código del producto como clave principal. Naturalmente, el código del producto también era una clave foránea en docenas de otras tablas. Por lo tanto, la renumeración fue realmente difícil y costosa y no se pudo hacer durante las horas de trabajo. La siguiente versión del software utilizaba ID artificiales, por lo que solo era una ACTUALIZACIÓN simple en la tabla de productos.

  • A veces, las claves naturales no son únicas, incluso si deberían serlo. En mis países, por algunas razones, se han emitido algunos SSN dos veces.

  • Las claves concentradas se vuelven engorrosas cuando la estructura de datos es compleja; Tener una sub-sub-sub-tabla con una clave oculta de 4 partes es bastante doloroso para trabajar.

Desventajas

  • Por su naturaleza, esas ID no tienen sentido fuera del sistema, por lo que necesita muchas búsquedas para traducir esas ID a claves naturales.

  • Obtener la clave superior de dicha sub-sub-sub-tabla requiere una gran unión a través de toda la jerarquía.

  • Fusionar datos entrantes con los registros existentes es más difícil, porque nuevamente se necesitan más búsquedas.

usuario281377
fuente
2
Bala 2: ¿Era esto antes ON UPDATE CASCADE?
Izkata
1
@Izkata, nunca permitiría la actualización en cascada en una base de datos de nivel empresarial, ya que es muy probable que cause problemas de rendimiento / bloqueo / bloqueo cuando se cambian grandes cantidades de registros. Realmente no desea bloquear a los usuarios mientras se actualizan 10,000,000 de registros. Es por eso que muchas personas creen que una clave volitil es mala, ya que causa demasiado trabajo en la base de datos cuando cambia.
HLGEM
@HLGEM Si bien admito que no he tenido una base de datos como esa para jugar, me parece que el bloqueo de nivel de fila de InnoDB ayudaría a mitigarlo, especialmente si se agregaron pausas entre la actualización de cada X registros. Además, tal como lo describió ammoQ, el problema real era que tendrían que cambiar manualmente todas las claves foráneas (el motor MyISAM en MySQL, por ejemplo, no lo admite).
Izkata
Izkata: El problema no era emitir 30 declaraciones de actualización en lugar de una. Esa parte es fácil, incluso sin usar actualizaciones en cascada. El verdadero problema estaba afectando a muchos miles de filas en lugar de una, causando puntos muertos en todo el sistema (ciertamente no muy bien diseñado). Finalmente, hubo un trabajo nocturno para hacer eso.
usuario281377
1
Desventaja +1: es más difícil mover datos entre diferentes entornos (desarrollo, producción, etc.)
Marco Lackovic
6

Las claves sintéticas frente a las claves naturales y las claves simples frente a las claves compuestas son temas muy debatidos que tienen buenos aspectos positivos y negativos en ambos lados. Son como las pestañas frente a espacios y corchetes en sus propios debates de línea.

Lo más importante es elegir un lado y mantenerlo para mantener la coherencia en toda la base de datos. generalmente las teclas sintéticas se usan simplemente porque es difícil tener una buena clave natural para cada tabla y es mucho más fácil ser consistente cuando cada tabla tiene una clave sintética.

Ryathal
fuente
4

Cada tabla debe tener una PK, un identificador único o una ID como la está llamando. En el caso de MxN, tiene PK (uno compuesto). Entonces no hay necesidad de tener otro.

Ver también: ¿ Una o dos claves principales en una tabla de varios a varios?

Mi preferencia personal relacionada con un tema relacionado: las PK no deberían tener otro uso aparte de ser una PK. Por lo tanto, no usaría datos aa PK, incluso si los datos son "naturalmente únicos" IE: SSN, fecha, código postal, etc.

Imbéciles
fuente
1
Te contradices a ti mismo. Las columnas de clave compuesta en la tabla de relación tienen otro uso además de ser una PK. También son claves foráneas. (Además, no estoy de acuerdo. Si tienes algo, eso es naturalmente PK, simplemente iría con él. Si no tuviera restricciones, seguramente terminaría con entradas en conflicto algún día y si la restricción está ahí, ¿por qué no usarla como clave principal?)
Jan Hudec
2
En general, los Pks se usan como FK en diferentes tablas que forman parte de ser un PK, no veo contradicción.
Morons
1
Entiendo su posición con respecto a las claves naturales, de esa manera tuve cuidado de decir que esta es mi preferencia personal.
Morons
3
@ JanHudec: Las cosas que son naturalmente únicas tienden a cambiar naturalmente. Además, he visto con bastante frecuencia que las claves naturales tienden a ser no enteras, como cadenas, lo que conduce a problemas de rendimiento si se usa como PK>
Goran Jovic
También te encuentras con problemas en los que tienes que lidiar con un error tipográfico en PK. Solía ​​volverme loco.
Morons
0

Desde el punto de vista del diseño, elija la clave primaria compuesta natural y no invente una clave sintética. Cualquier cosa que no tenga que estar allí solo hace que el esquema sea más complicado de entender.

Desde el punto de vista del rendimiento en muchas bases de datos, es más rápido acceder a la tabla por clave primaria entera que por cualquier otra columna indexada. Estas bases de datos también agregarán implícitamente dicha clave sintética a cualquier tabla que no tenga una (generalmente llamada "rowid" u "oid" o similar), por lo que agregarla explícitamente no costará nada.

Para las tablas MxN (relación) no tiene sentido acceder a ellas por clave primaria; puede acceder a ellos por cualquiera de los componentes y obtener el conjunto de entidades relacionadas desde el otro lado. Por lo tanto, para estas tablas no tiene sentido agregar una clave primaria sintética.

Para otras tablas con una clave primaria bien compuesta o no entera, todavía no agregaría una sintética inicialmente, pero consideraría agregarla durante el ajuste de rendimiento para tablas a las que se accede en tablas críticas de rendimiento.

Jan Hudec
fuente