[lbuelvas]

Hola amigos foristas, la pregunta planteada por el compañero mjjj es bastante interesante y ha sido tema de mutiples discusiones.

Quiero comentar sobre las tres primeras tablas. Ambas aproximaciones son válidas, sin embargo quiero replantear el modelo del negocio de la siguiente manera: Imaginemos que necesitamos registrar informacion sobre usuarios o clientes y tambien registrar la informacion de empresas; en cada empresa pueden laborar uno o mas usuarios y cada usuarios pueden trabajar en una o mas empresas.

Caso 1:
Tablas:
usuarios (id, nombre, apellido) PK: id
empresas (id, nombre) PK: id
empresa_usuario (id_usuario, id_empresa) PK: id_usuario, id_empresa

Caso 2:
Tablas:
usuarios (id, nombre, apellido) PK: id
empresas (id, nombre) PK: id
empresa_usuario (id, id_usuario, id_empresa) PK: id

Hay algo que normalmente no se enseña en cursos básicos de bases de datos y es la dinámica del tiempo. Cuando diseñemos bases de datos debemos pensar que el sistema se va a utilizar no por un año sino por un periodo de al menos 5 años. Los 2 modelos nos permite indicar el usuario para que empresa trabaja, pero preguntemonos: El usuario puede renunciar a una de las empresas y un tiempo despues puede volver a trabajar en esa misma empresa, en esta situación y solo con tres tablas el caso 1 no nos sirve, el caso 2 es mas flexible en cuanto a diseño.

Esto nos lleva a que cuando nos encontremos con una relación m:n (eviten escribir m:m porque se estaría diciendo que existe igual numero de elementos en cada una de las entidades) pensemos en que no solo se resuelve con una tabla de asociación sino que esa tabla de asociación puede ayudarnos a "enriquecer" el modelo.

Entonces esa tabla empresa_usuario podria quedar asi:

empresa_usuario
(
id not null,
id_usuario not null,
id_empresa not null,
estado not null
fecha_ingreso not null,
fecha_egreso
) PK: id

El campo estado puede decirnos si esta vinculado, suspendido, contrato cancelado,etc.

Fecha de ingreso como su nombre lo indicanos dira cuando se establecio esa relación y fecha de egreso tendrá un valor null hasta que haya finalizado la relación del usuario con la empresa.

Sobre si es mejor las tablas identificarlas con un identificador único entero (ID) es algo que defienden los puristas defensores del modelo orientado a objetos, es muy flexible pero la construcción de aplicaciones y elaboración de consultas es mas compleja y no tan eficiente como con la creación de llaves "relacionales" (mas de un atributo). Ambas aproximaciones (relacional y de objetos) tienen sus ventajas y desventajas, por eso utilizo una u otra o una mezcla de ambas dependiendo de la situación que deba resolver de forma que mantenga un equilibrio entre simplicidad y efciencia.