¿Estos estilos de diseño de base de datos (o antipatrón) tienen nombres?

Question

Considere una base de datos con tablas Productos y empleados. Existe un nuevo requisito para modelar a los gerentes de productos actuales, siendo el único empleado responsable de un producto, señalando que algunos productos son lo suficientemente simples o maduros para no requerir un gerente de producto. Es decir, cada producto puede tener cero o un gerente de producto.

Enfoque 1: alter table Product para añadir una nueva columna NULL capaces product_manager_employee_ID de manera que un producto con ningún gerente de producto es modelado por el valor NULL.

Enfoque 2: crear una nueva tabla con los no ProductManagersNULL columnas capaces product_ID y employee_ID, con una restricción única en product_ID, por lo que un producto sin gerente de producto es modelado por la ausencia de una fila de esta tabla.

Hay otros enfoques, pero estos son los dos que parece encontrar más a menudo.

Suponiendo que estas son opciones de diseño legítimo (como me inclino a creer) y simplemente representan diferentes estilos, ¿tienen nombres? Prefiero el enfoque 2 y me resulta difícil transmitir la diferencia de estilo a alguien que prefiere el enfoque 1 sin emplear un ejemplo real (¡como lo he hecho aquí!) Sería bueno si pudiera decir: "Prefiero el inclinación hacia el estilo 6NF (o lo que sea) yo mismo ".

Suponiendo que uno de estos enfoques es de hecho un antipatrón (como sospecho que puede ser el caso para el acercamiento 1 al modelar una relación entre dos entidades como un atributo de una de esas entidades) ¿este antipatrón tiene ¿un nombre?

Answer 1

Bueno, el primero es nada más que una relación uno a muchos (un empleado a muchos productos). Esto a veces se denomina relación O: M (cero a muchos) porque es opcional (no todos los productos tienen un administrador de productos). Además, no todos los empleados son administradores de productos, por lo que también es opcional.

La segunda es una tabla de unión, generalmente utilizada para una relación de muchos a muchos. Pero dado que un lado es solo uno a uno (cada producto está solo en la mesa una vez), en realidad es solo una complicada relación de uno a muchos.

Personalmente prefiero la primera, pero ninguna de las dos es incorrecta (ni mala).

El segundo se usaría por dos razones que se te ocurren.

1. Visualiza la posibilidad de que un producto tenga más de un administrador; o
2. Desea rastrear el historial de quién es el gerente de producto para un producto. Haga esto con, digamos una columna current_flag establecida en 'Y' (o similar) donde solo una a la vez puede ser actual. Este es en realidad un patrón bastante común en aplicaciones centradas en bases de datos.

Answer 2

Me parece que los dos modelos tienen un comportamiento diferente. En el primer ejemplo, puede tener un gerente de producto por producto y un empleado puede ser gerente de producto para más de un producto (uno para muchos). El segundo parece permitir más de un administrador de producto por producto (muchos a muchos). Esto sugeriría que las dos soluciones son igualmente válidas en diferentes situaciones y cuál usar dependerá de la regla de negocio.

Answer 3

Hay una falla en el primer enfoque. Imagine por un momento que los requisitos del negocio han cambiado y ahora necesita poder configurar 2 Product Manager para un producto. ¿Qué harás?Agregue otra columna a la tabla Producto? Yuck. Obviamente, esto viola 1NF.

Otra opción que ofrece el segundo enfoque es la capacidad de almacenar algunos atributos para un determinado Product Manager < -> Relación del producto. Por ejemplo, si tiene dos Product Manager para un producto, puede configurar uno de ellos como principal ... O, por ejemplo, un empleado puede tener un número de teléfono, pero como gerente de producto puede tener otro número de teléfono ... Esto también va a la mesa especial entonces.

Answer 4

Enfoque 1)

1. ralentiza el uso de la tabla del producto con el campo adicional Product Manager (quizás no para todas las bases de datos, pero para algunos).
2. La vinculación de la tabla Producto a la tabla Empleado es simple.

Enfoque 2)

1. consultas existentes que utilizan la tabla del producto no se ven afectadas.
2. Aumenta el tamaño de su base de datos. Ahora ha duplicado la columna ID de producto en otra tabla, así como también ha añadido restricciones e índices exclusivos a esa tabla.
3. La vinculación de la tabla Producto a la tabla Empleado es más engorrosa y costosa, ya que primero debe aplicar tinta a la tabla intermedia.

¿Con qué frecuencia debe unir las dos tablas?

¿Cuántas otras consultas utilizan la tabla Producto?

¿Cuántos registros hay en la tabla Producto?

Answer 5

en el caso particular que proporcione, creo que la principal motivación para dos tablas es evitar los nulos por datos faltantes y así es como caracterizaría los dos enfoques.

hay una discusión sobre los pros y los contras on wikipedia.

estoy bastante seguro de que, dada la desagradable opinión de c date, él define la teoría relacional para que solo la solución de tabla múltiple sea "válida". por ejemplo, puede llamar al método de tabla única "mal tipado" (dado que el tipo de nulo es unclear - vea la cita en p4).