¿Cómo convencer a alguien de normalizar una base de datos?

Question

Así que he estado trabajando en este proyecto en el trabajo donde estoy codificando un sitio web php que interactúa con una base de datos que no tengo control. La base de datos fue "diseñada" por un compañero de trabajo que ha estado con la compañía muchos años más que yo; así que al final las decisiones se dejan para que decidan.

Cuando me subieron por primera vez a este proyecto, fui a un compañero de trabajo y le expliqué que el esquema de la base de datos parecía defectuoso. Expliqué la importancia de normalizar la base de datos para asegurar problemas de integridad de los datos, ahorrar espacio en el disco y facilitar el trabajo del programador (yo). Incluso di ejemplos de cómo podrían ocurrir anomalías de inserción, eliminación y actualización en el diseño actual. Sin embargo, el compañero de trabajo me explicó que no querían complicar demasiado la base de datos del proyecto, y que no cambiaría el período.

Así que ahora llevo un par de meses en el proyecto y me estoy tirando de los pelos cada vez que tengo que unir dos tablas para insertar un valor en un atributo que tiene una relación de uno a uno con el otro. (Así que el atributo debería haber sido solo un atributo de la relación principal). La base de datos se ve horrible, y me temo que en el futuro esto me volverá a la mente ya que programé la interfaz que usa la base de datos.

¿Alguien tiene alguna sugerencia sobre cómo hablar con un compañero de trabajo "superior" para que diseñe correctamente una base de datos? ¿O alguna sugerencia sobre cómo evitar ser condescentrado años en el camino para un diseño del que yo no tenía parte? ¿Debo negarme a trabajar en proyectos como este en el futuro? Deje un comentario en mi código que dice que la base de datos no fue cosa mía.

Gracias.

Editar: Información adicional en respuesta a los comentarios ...

sé que el de-normalización de una base de datos puede ser útil para los propósitos de velocidad, así que no estoy pasando por alto esto. Para aquellos que leen y no han escuchado sobre esta táctica, ilustraré un ejemplo. A menudo, los diseñadores de bases de datos tienen una relación de dirección que enumera la calle, la ciudad, el estado y el código postal de un usuario. Si bien todos saben que un código postal determina la ciudad y el estado, por lo tanto constituye una tabla que indexa los códigos postales de ciudades y estados. A menudo, los diseñadores de bases de datos combinarán las dos tablas, desnormatizándolas con previsión de que cada consulta para la dirección de un usuario requerirá una unión de la tabla de direcciones a la tabla comprimida. Esto, en última instancia, acelera el proceso de consulta, y es un razonamiento sensato para la des-normalización de partes de un diseño de base de datos.

Para completar aquí algunos detalles, la base de datos está diseñada para un sistema de Solicitud de viaje, por lo que los datos están relacionados con la información del visitante, fechas, etc. El esquema que utiliza la base de datos actual es impredecible de principio a fin. Desde las incoherencias más simples en los patrones de nomenclatura de variables (por ejemplo: num_of_visitors, arrivalMethod, etc.) hasta tener relaciones separadas definidas para un atributo de estado individual de uno a uno. Ejemplo: statusID representa el estado de la solicitud de recorrido, solo puede tener un estado válido seleccionado de un grupo de estados posibles (Aprobado, denegado, pendiente, cancelado). Por alguna razón, la base de datos tiene una tabla de estado que contiene: tour_id (Principal clave de la relación de gira), ID de estado. Esto permite que se definan múltiples estados para cada solicitud de viaje. Que, por diseño, una solicitud de recorrido solo debe estar en un estado en un momento dado. Entonces, es un defecto en el diseño, no un descuido mío.

Answer 1

Desde mi experiencia, este tipo de situaciones a menudo terminan siendo batallas difíciles de ganar, desafortunadamente. Un par de cosas que puede hacer para distanciarse de diseño podrían ser:

• Aplicar una capa de acceso a datos en el código que abstrae tanto del diseño de base de datos real como sea posible. De esta forma, puede estructurar su código en un mejor formato y "distanciarse" efectivamente de usar y ser culpado por el mal diseño de la base de datos.
• Crear vistas de la base de datos para acceder a los datos en un formato más lógico
• Hacer pequeños refactorizaciones a las tablas/código cuando tienes la oportunidad, si puede salirse con la suya

Yo no pondría comentarios derogatorios en el código, porque lo más probable es que vuelva a perseguirte. En su capa de acceso a datos, puede incluir comentarios objetivos/no ofensivos que expliquen por qué está abstrayendo un diseño en particular y cómo podría diseñarse de manera diferente.

Si las cosas son realmente malas y nadie más lo apoyará, tal vez sea hora de buscar otro trabajo.

Answer 2

Cambiar de trabajo.

EDIT:

La respuesta corta es no, ya que estoy bromeando o no tomar en serio la cuestión. He estado en una situación así antes. La mala base de datos no es el problema. El problema es la gestión ciega o ignorante.Quiero decir, si no saben o no les importa que las decisiones técnicas importantes sean tomadas por personas incompetentes, entonces las cosas empeorarán. Es como caminar hacia un pantano.

En serio, considere buscar un nuevo trabajo. Realmente hay grandes lugares de trabajo para un desarrollador. Este no es Estás perdiendo tu tiempo.

Answer 3

Quizás pueda especificar las operaciones que necesita realizar en esta base de datos y sugerir que las implemente como procedimientos almacenados en la base de datos? ... Definitivamente pondría el problema donde corresponde ... con la persona que lo causó.

Answer 4

La manera más positiva sería trabajar con un compañero de trabajo y tratar de evolucionar y educar su forma de pensar. Tal vez discutir los errores que ha cometido en el pasado sea una forma sencilla de romper el hielo y mostrarle las implicaciones de un sistema mal diseñado.

Si no tiene muchas malas experiencias pasadas para ayudarlo, le sugiero que registre cuánto tiempo (tiempo o dinero) tardan en completar las tareas/defectos específicos. A continuación, puede generar estadísticas, a todos los administradores les encanta un gráfico, que con suerte mostrará cómo ha aumentado con el tiempo el tiempo requerido para agregar funcionalidad o resolver defectos.

Espero que esto ayude.

Answer 5

Esta pregunta podría reformularse para incluir cualquier diseño e implementación independientemente del dominio del problema.

Es una gran causa de frustración cuando te encuentras en una situación como esta. Afortunadamente, no me he metido en esto más que unas pocas veces y he podido evitar en gran medida las partes del SW que se vieron afectadas. O crea una capa intermedia que te permita utilizar un diseño de base de datos más sensato.

Si el diseñador sénior y la gerencia no se preocupan, generalmente no hay mucho que hacer. Es lo mismo cada vez que se requiere un cambio para sw que ha existido por un tiempo. Obtener los cambios aprobados por personas que diseñaron el sistema en primer lugar es a menudo imposible por varias razones psicológicas a menos que usted sea el superior y pueda "forzar" el problema. Y aun así, en algunos casos podría no ser posible (es posible que termine necesitando demasiados cambios en su sw).

Una posibilidad sería, sin embargo, si tiene problemas específicos, como el rendimiento.Si puedes demostrar que un mejor diseño de db resolvería estos problemas, podrías avanzar un poco.

Answer 6

Tratar de ocultar la base de datos mal diseñada detrás de una capa es solo un "truco" y la OMI debería ser el plan B. Para el plan A, trataría de "escalar" a un nivel superior.

Como describió, no tiene autoridad para influir en la persona que ensucia la base de datos. Luego iría al arquitecto (suponiendo que haya uno) o al gerente del proyecto si no hay arquitecto.

Es muy importante mantener sus argumentos con hechos bien documentados sobre el impacto que el mal diseño ya tiene en el sistema que está construyendo. Otros hechos podrían ser problemas conocidos para la base de datos mal diseñada de las comunidades de db especializadas.

No tengo suficiente información acerca de su situación, pero esto es lo que generalmente trato de hacer cuando me enfrento con clientes que insisten en una solución técnica mal diseñada.

Answer 7

A menudo, un desarrollador necesita trabajar con un cliente que solicita cosas absurdas o necesita mantener/trabajar con un código heredado que está muy mal diseñado. Por supuesto, debe tratar de convencer/educar a sus colegas sobre cómo se debe diseñar una base de datos, pero su principal esfuerzo debe ser proporcionar un código fuente de la mejor calidad. La mayoría de las veces, uno necesita lidiar con tales situaciones.

Recomendaría seguir un consejo ya dado para crear una capa alrededor de la base de datos. Rellene con comentarios como "Hacer esto complicado porque db tabla 1 y 2 no están normalizados". No pongas crítica en tus comentarios. Mantenerlos estrictamente técnicos. De vez en cuando discuta con sus colegas/gerente sobre el diseño de la base de datos. Compre un libro relacionado y póngalo en un lugar para que todos lo vean. Cuando alguien pregunta, ofrécete a prestarlo. Aún así, sus principales esfuerzos deberían ser escribir un buen código.

Answer 8

Llévelos al sótano. Dale una opción entre llevar un sofá grande o 4 sillas pequeñas :)

Answer 9

Cuando dice que no quiere complicar demasiado la base de datos, tal vez quiso decir que no sabe o no es competente para normalizar las bases de datos . En ese caso, una forma sería tratar de convencerla de los beneficios de normalizar y enviarla a estudiar la normalización de la base de datos. Una razón para normalizar sería que la creación de una base de datos no es el único requisito para una base de datos. La base de datos existe porque se usa como almacenamiento de datos. ¿Y qué almacena los datos? El software de la aplicación. Por lo tanto, el creador de la base de datos debe honrar tanto al desarrollador de software que normalice la base de datos. De lo contrario, sería una situación realmente incómoda. Para facilitar las cosas, podría mostrar algunas operaciones de normalización más simples al principio para comenzar.

Answer 10

Es posible que no pueda persuadir al diseñador de la base de datos para que vuelva a trabajar en la base de datos, especialmente si ya existe una gran cantidad de código escrito contra la base de datos tal como existe.

Sin embargo, necesita ampliar su vocabulario para describir la diferencia entre una base de datos bien diseñada y una mal diseñada. Hay muchos diseños de bases de datos incorrectos que no pueden corregirse simplemente mediante la normalización. El único ejemplo que da es desgarrarse porque tiene que unir datos de tablas separadas cuando un buen diseño hubiera puesto los datos en la misma tabla.

Descomponer una tabla que debería haberse dejado compuesta normalmente no es una falla en la normalización. Casi todas las fallas en la normalización resultan en tablas compuestas que deberían haberse descompuesto. de tus comentarios sobre cómo entrenarla en las anomalías de actualización, estoy bastante seguro de que ya sabes lo que sea que pueda enseñarte sobre las formas normales.

La descomposición de tablas por malas razones, a veces conocida como "hipernormalización", es un sabor diferente de la falla de diseño. Los problemas de programación que surgen de este defecto son muy diferentes de los que surgen de la infranormalización.

¿Cuántos otros programadores desarrollan código que funciona en la misma base de datos? ¿Cómo se sienten los demás programadores sobre el diseño? Si son realmente felices, eso reduce aún más tus posibilidades de cambiar las cosas. Si todos están desorientados, puede persuadir al diseñador encontrando fuerza en los números. Lo sé, lo sé, eso es política, y apuesto a que odias la política.

Cuando solía enseñar a los programadores sobre programación y diseño de bases de datos, los estudiantes a menudo preguntaban por qué había tanta política en el trabajo de bases de datos. Finalmente me vino una respuesta simple:

Cuando una base de datos está en uso amplio, se produce el intercambio de datos. Eso implica compartir conocimiento. El conocimiento es poder. Cuando se comparte el poder, la política sucede.

Answer 11

Encuentra un error causado por la desnormalización. Si la base de datos no tiene las restricciones adecuadas (y supongo que no será en las circunstancias), existe un error . Yo pondría dinero en eso. Si estás usando un rastreador de errores, mira allí. Si no, resuélvelo usted mismo. De cualquier manera, puede demostrar cuánto daño puede causar un error y cuánto cuesta limpiar.

Answer 12

Muestre a los altos directivos esta pregunta. Eso les mostrará que la normalización de una forma u otra no es solo una "complicación" de una base de datos, sino un procedimiento estándar que la abrumadora mayoría de los desarrolladores competentes considera fundamental.