¿Es esta una forma ridícula de estructurar un esquema de base de datos, o me estoy perdiendo algo?

Tiene mucho sentido para mí. Es simplemente muy normalizado, lo que le confiere una gran flexibilidad que de otra manera no tendría. Los datos des-normalizados son un dolor en el trasero.

No creo que un WTF esté garantizado o que el tipo esté haciendo algún tipo de diseño de genio loco, es una normalización de base de datos bastante estándar.

El motivo de la tabla de departamentos es que si no coloca los departamentos en una tabla separada, tendrá que tratar con los usuarios en "Ventas", "Ventas", "Vendedores", "Velas" y "Ventas "Departamentos, a menos que hagas algo para evitarlo. Y tener la mesa extra es (parte de) la mejor manera que conozco para hacerlo.

Si debe haber una tabla de UserDepartment es una llamada más difícil, lo que por supuesto significa que ninguna decisión está muy lejos. Por un lado, es un problema cuando todo el diseño y la lógica de su mesa han asumido un departamento por usuario y luego eso cambia, por otro lado, hacer una unión adicional sin ninguna razón por años y años es una posibilidad real y también un dolor.

Personalmente estaría de acuerdo con usted en que la tabla UserDepartment es probablemente una exageración. Incluso si está incluido, lo más probable es que con el tiempo la gente escriba consultas que asuman que solo hay un usuario por departamento, por lo que terminará con el peor de los dos mundos: una combinación adicional sin ninguna razón antes de necesitar la mesa. El código no funciona de todos modos una vez que se permite más de un departamento por usuario.

EDITAR - Un factor clave para determinar si se debe admitir la relación de muchos a muchos es si las reglas comerciales son claras. Si no tiene idea de cómo funcionaría un usuario en varios departamentos, no tiene mucho sentido agregar la tabla, ya que su código posiblemente no puede manejar correctamente los casos en que un usuario está en varios departamentos.

Imagina que permitiste muchos departamentos por usuario, por si acaso. Luego implementó una regla de negocios para asignar comisiones, según el departamento. Luego se permitieron múltiples departamentos. Afortunadamente, también tuvo la previsión de escribir su código de comisión de una manera que tuviera esto en cuenta. Desafortunadamente, usted agregó las comisiones de cada departamento para los usuarios en ambos. La gerencia quería que usted se base en el rol de las personas para cada venta. Entonces, ¿cuánto bien fue tener la mesa por adelantado? ¿Qué pasa con las otras tablas que tenía "por si acaso" que nunca son necesarias?

EDICIÓN POSTERIOR - Otra razón por la que el consultor podría haber querido agregar todas esas tablas intermedias se aborda en esta pregunta de seguimiento , cuyas respuestas dan algunas razones por las que la refactorización de una base de datos suele ser más difícil que el código de refactorización, que tendería a empujarlo hacia el" lugar en todas las tablas que pueda necesitar "enfoque".

Si el requisito es tener varios departamentos por usuario, este diseño tiene sentido. La única queja al respecto es que UserDepartmentTable tiene una clave sustituta UserDepartmentID que no es necesaria (solo haga que UserId y DepartmentId sea una clave primaria compuesta).

Si un usuario solo pertenece a un solo departamento, su diseño tiene sentido (aunque una tabla de búsqueda de departamento aún sería una buena idea).

Algunos requisitos no están claros en su pregunta. La respuesta correcta depende de lo que su cliente quiera. Si yo fuera usted, le preguntaría al cliente sobre esto:

0: ¿Cuál es la diferencia entre un usuario y un empleado?

1-Asumiendo un empleado = usuario, ¿qué sucede si un empleado cambia de departamento?

2-¿Puede un grupo de empleados realizar una solicitud?

3-¿Podría un empleado pertenecer a más de un departamento? ¿Qué pasa con el CEO

4-¿Hay algún subconjunto de empleados que puedan realizar solicitudes?

5-¿Qué sucede con la solicitud cuando se elimina un registro de empleado (si es que lo hace)?

6-¿Podrías eliminar una solicitud? Qué sucede cuando se elimina la solicitud (asegúrese de no eliminar el registro de empleado por RI)

7-¿Puede el empleado hacer la solicitud "igual" más de una vez (definir la "misma")

8-¿Cómo manejar las solicitudes de los empleados cuando dejan la empresa (cancelar sus solicitudes o eliminarlas)?

Puede haber más preguntas, pero mi punto es que la solución depende de los requisitos exactos y el alcance del proyecto. Una vez que se determina eso, el esquema se puede derivar directamente. En consecuencia, ambas soluciones presentadas pueden ser correctas.

Me gustaría agregar un par de notas de formulario de puntos que hablen explícitamente sobre algunas de las ventajas potenciales de usar una tabla de unión de la manera en que lo hizo su asesor altamente pagado.

• Indizado correctamente (por ejemplo, si UserDepartmentTable indexa las dos claves foráneas), solo hay una pequeña pérdida de rendimiento de una tabla de combinación como esta debido a que las claves foráneas no son únicas. Si se garantiza que las claves externas son únicas, la teoría de la pequeña base de datos que conozco, buscar UserDepartmentTable.Department no es "más difícil" que buscar cualquier otra columna en la tabla User .
• La tabla de unión le brinda más flexibilidad para configurar otra información sobre la asociación entre el usuario y el departamento (por ejemplo, las marcas de tiempo en la creación).
• La tabla de unión le permite "crear una versión" de la asociación con bastante facilidad (por ejemplo, cuando un usuario cambia de departamento, activa algún indicador booleano de índice como UserDepartmentTable.Active en falso y crea una nueva asociación que esté activa). También es posible tener versiones de asociación de departamento con el modelo de dos tablas (solo Usuario y Departamento), pero es más difícil y requiere agregar al menos una columna más o hacer acrobacias en la base de datos para evitar la duplicación de claves primarias.
• Le permite asignar asociaciones de uno a muchos o de muchos a uno o de muchos a muchos con bastante facilidad.

Dicho esto, hay varias razones para NO hacer lo que hizo su asesor altamente pagado.

• Todos los beneficios anteriores son anticipadores de posibles necesidades futuras, lo que complica las cosas en la actualidad. No es compatible con YAGNI. Más tarde, resulta de una dificultad trivial escribir una migración que se traslada de su modelo de dos tablas a un modelo de tabla de unión. Puedes hacer eso cuando surja la necesidad del negocio. Hacerlo antes puede ser confuso.
• Confunde a otros desarrolladores. Si bien, sí, diría que la expectativa de un desarrollador web de su categoría (en la que está revisando las decisiones de los consultores) sería comprender y reconocer una tabla de uniones, es aún más complicado de lo necesario y considerando la falta de necesidad comercial. causa confusión.

Sin la estructura completa de la información necesaria, no puedo decir si es terrible o no. Pero al menos la pieza mostrada no es de diseños "WTF". Simplemente parece una 3ª forma normal de estructura de datos (bueno, en teoría también tenemos 4ª y 5ª)

Algunas charlas pueden tener lugar para la tabla de usuario de usuario entre dos escuelas de claves "naturales" y "artificiales" en la pieza mostrada. Nada más, como puedo ver

La normalización es la regla de un buen desarrollador / diseñador de bases de datos por muchas razones, * de * las normalizaciones se usan a veces en medio de los desarrollos para ganar en gran medida en su mayoría