Hay un montón de mesas en las que es posible que desee tener una columna de identidad como clave principal. Sin embargo, en el caso de una tabla de relaciones M: M que describa, la mejor práctica es NO usar una nueva columna de identidad para la clave principal.
El enlace de RThomas en su comentario proporciona las excelentes razones por las cuales la mejor práctica es NO agregar una columna de identidad. Aquí está that link.
Las desventajas superarán a los profesionales en casi todos los casos, pero como usted pidió ventajas y desventajas, también puse un par de profesionales poco probables.
Contras
añade complejidad
puede llevar a duplicar las relaciones a menos que refuerce la singularidad de la relación (que una clave principal haría por defecto).
Probablemente más lento: db debe mantener dos índices en lugar de uno.
Pros
todos los pros son bastante mediocre
Si tuviera una situación en la que tenía que usar la clave principal de la tabla de relación como una unión a una tabla separada (por ejemplo, una tabla de auditoría?) la unión probablemente sea más rápida. (Como se señaló, agregar y quitar registros probablemente sea más lento. Además, si la tabla de relaciones es una relación entre tablas que usan identificaciones únicas, el aumento de velocidad de usar una columna de identidad en la combinación frente a dos será mínimo).
La aplicación, por simplicidad, puede suponer que cada tabla con la que trabaja tiene una ID única como clave principal. (Es un diseño pobre en la aplicación, pero es posible que no tenga control sobre él). Podría imaginarse un escenario en el que es mejor introducir cierta complejidad adicional en el DB que la complejidad adicional en dicha aplicación.
Artículo simple sobre el pro de claves compuestas: http://weblogs.sqlteam.com/jeffs/archive/2007/08/23/composite_primary_keys.aspx – RThomas
sin necesidad de una columna de identidad, la clave principal es básicamente un conjunto de columnas (1 o más) que definen de manera única sus datos. Al agregar una columna de identidad, está agregando un índice adicional, y haciendo que el índice sea probablemente el que más use (con las 2 columnas importantes) como no agrupado, además las actualizaciones/inserciones serán un poco más lentas, etc. etc. Básicamente, no es necesario. – Rodolfo
@RThomas - En ese weblog, están utilizando una relación Clientes-> Productos que no debería tener una clave compuesta ya que indica datos transaccionales. No * puede * haber múltiples relaciones creadas en diferentes momentos, esa tabla necesita una Identidad única PKey. por ejemplo, pedir botellas de vino, bajo el mismo SKU - referenciado por un solo ProductID - (no ideal, pero posible). Pero, si cada botella tiene su propia identificación, entonces el "límite de orden" es irrelevante ya que debe crear un registro de transacción separado para cada artículo. O ha construido la estructura incorrectamente o está realizando el seguimiento incorrecto de los datos. – hajikelist