Una queja acerca de como implemento las asociaciones muchos-a-muchos en la base de datos

Me ha llegado una queja acerca de la estrategia de implementación de asociaciones M:N en SQL que sigue mi servicio de generación online UMLtoSQL .

En particular, la queja va de que en la traducción del diagrama siguiente:

la asociación Recommends se implementa como una tabla indendiente con un campo de tipo autoincrement como PK , como se puede ver en el siguiente trozo de código SQL DDL (el script completo se puede encontrar aquí , puede variar dependiendo de la base de datos para la que se esté generando el modelo):

 -- Table for storing the data of  Recommends
  CREATE TABLE Recommends_rt(
    id INTEGER(5) NOT NULL AUTO_INCREMENT,
    -- Attribute referencing the customer
    customer INTEGER(5) NOT NULL ,
    -- Attribute referencing the book
    book INTEGER(5) NOT NULL ,
    CONSTRAINT pk_Recommends PRIMARY KEY (id),
    CONSTRAINT u_Recommends1 UNIQUE (customer,book)
  );

  ALTER TABLE Recommends_rt
    ADD CONSTRAINT fk_RecommendsToCustomer_customer FOREIGN KEY(customer)
      REFERENCES Customer_rt(id)
      ON DELETE restrict
      ON UPDATE cascade;

  ALTER TABLE Recommends_rt
    ADD CONSTRAINT fk_RecommendsToBook_book FOREIGN KEY(book)
      REFERENCES Book_rt(id)
      ON DELETE restrict
      ON UPDATE cascade;

Quisiera remarcar que ésta es una decisión plenamente consciente. Ya sé que la forma “tradicional” de implementar este tipo de asociaciones es con una clave primaria compuesta (en este caso seria customer + book) pero creo que la estrategia implementada en el servicio online es mejor por dos razones:

• Garantiza el mismo nivel de integridad de los datos: la restricción que en la forma “tradicional” garantiza la PK compuesta (que no pase que un cliente recomiende dos veces el mismo libre) se comprueba en mi caso con la clave de tipo Unique sobre los mismos atributos
• Es una solución más pragmática (y que de hecho adapte después de hablar con gente trabajando en empresas de desarrollo). Los dos problemas principales de las claves compuestas son: 1 – Propagación de estas claves cuando la tabla en cuestión participa en otras asociaciones (con el efecto en cascada que esto ocasiona que puede llevar a tener tablas con PKs de 4 o 5 atributos) y 2 – Dificultad en la implementación de la interfaz de usuario (ahora siempre hay que tener en cuenta la posibilidad de encontrarnos con tablas con PK compuestas)

¿Que pensáis? ¿Cuál es vuestra estrategia? ¿Sois pragmáticos o más bien puristas?

Por cierto que la queja acaba con la frase “you’re clearly pandering TO the RoR/Django crowd who have forgone good design IN the NAME OF make their ORM tools easier TO WRITE” . RoR/Django fans, protestad!!

Si te ha gustado esta entrada, puedes subscribirte a este Software Modeling blog y/o seguirme en twitter y/o a través de la lista de distribución del portal Y si realmente te ha gustado ayúdame a hacerlo llegar a otros utilizando los bookmarks que tienes a continuación: