database - normalizacion - normalization definition
¿Cómo convencer a alguien para que normalice una base de datos? (12)
¿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 pertenece ... con la persona que lo causó.
Así que he estado trabajando en este proyecto en el trabajo donde estoy codificando un sitio web de PHP que interactúa con una base de datos sobre la que no tengo control. La base de datos fue "diseñada" por un compañero de trabajo que ha estado en la empresa muchos años más que yo; Así que al final las decisiones quedan por decidir.
Cuando me subieron a bordo de este proyecto, fui con 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 los problemas de integridad de los datos, el ahorro de espacio en el disco y que eso facilitaría 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 la base de datos del proyecto y que eso no cambiaría el período.
Así que ahora llevo un par de meses en el proyecto y me arranco el pelo cada vez que tengo que unir dos tablas para insertar un valor en un atributo que tiene una relación de uno a uno entre sí. (Entonces, 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 los próximos años esto volverá a aparecer desde que programé la interfaz que usa la base de datos.
¿Alguien tiene alguna sugerencia sobre cómo convencer a un compañero de trabajo "superior" para que diseñe correctamente una base de datos? ¿O alguna sugerencia sobre cómo evitar obtener años de patrocinio en el camino para un diseño del que no formé parte? ¿Debería simplemente negarme a trabajar en proyectos como este en el futuro? Deja un comentario en mi código diciendo que la base de datos no estaba haciendo mi?
Gracias.
Edit: Información adicional en respuesta a los comentarios ...
Sé que la des-normalización de una base de datos puede ser útil para propósitos de velocidad, así que no me olvido de esto. Para aquellos que no hayan oído hablar de 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, constituyen una tabla que indexa los códigos postales de la ciudad y los estados. A menudo, los diseñadores de bases de datos combinan las dos tablas, des-normalizándolas con la previsión de que cada consulta para la dirección de un usuario requeriría una unión de la tabla de direcciones a la tabla zip. En última instancia, esto acelera el proceso de consulta y es un buen razonamiento para la des-normalización de partes del diseño de una base de datos.
Para completar algunos detalles aquí, la base de datos está diseñada para un sistema de solicitud de recorridos, por lo que los datos se relacionan con la información del visitante, las fechas, etc. El esquema que utiliza la base de datos actual es impredecible de principio a fin. Desde las inconsistencias más simples en los patrones de nombres de variables (ejemplo: num_of_visitors, arrivalMethod, etc.) hasta tener relaciones separadas definidas para un solo estado de atributo 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 (Primario clave de la relación de viaje), statusID. Esto permite que se definan múltiples estados para cada solicitud de recorrido. Que, por diseño, una solicitud de recorrido solo debe estar en un estado en un momento dado. Así que es un defecto en el diseño, no un descuido mío.
A menudo es el caso que un desarrollador necesita trabajar con un cliente que solicita cosas absurdas o necesita mantener / trabajar con código heredado que está muy mal diseñado. Por supuesto, debe intentar convencer / educar a sus colegas sobre cómo debe diseñarse una base de datos, pero su principal esfuerzo debe ser proporcionar el 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. Rellénelo con comentarios como "Hacer esta cosa complicada porque las tablas 1 y 2 de la base de datos no están normalizadas". No pongas críticas en tus comentarios. Mantenlos estrictamente técnicos. De vez en cuando, hable con sus colegas / gerente sobre el diseño de la base de datos. Compre un libro relacionado y póngalo en un lugar donde todos puedan verlo. Cuando alguien pregunta, ofrécete a prestarlo. Aún así, tus principales esfuerzos deberían ser escribir un buen código.
Cambia de trabajo.
EDITAR:
La respuesta corta no es porque estoy bromeando o no estoy tomando la pregunta en serio. 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 que si no saben o no les importa que las personas incompetentes tomen decisiones técnicas importantes, entonces las cosas empeorarán. Es como entrar en un pantano.
Considerar seriamente la búsqueda de un nuevo trabajo. Realmente hay grandes lugares de trabajo para un desarrollador. Este no lo es. Estás perdiendo tu tiempo.
Cuando dice que no quiere complicar en exceso 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 la normalización y enviarla a la normalización de la base de datos del estudio. Una razón para normalizar sería que solo crear una base de datos no es el único requisito para una base de datos. La base de datos existe porque se utiliza como almacenamiento de datos. ¿Y qué almacena los datos? El software de aplicación. Así que el creador de la base de datos debe honrar tanto al desarrollador de software que normaliza 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 con ellas.
Desde mi experiencia, este tipo de situaciones a menudo terminan siendo batallas imposibles de ganar, desafortunadamente. Algunas cosas que puede hacer para distanciarse del diseño podrían ser:
- Implemente una capa de acceso a datos en el código que abstraiga la mayor parte posible del diseño de la base de datos real. De esta manera, puede estructurar su código en un mejor formato y efectivamente distanciarse del uso y ser culpado por el mal diseño de la base de datos.
- Cree vistas en la base de datos para acceder a los datos en un formato más lógico.
- Haga pequeñas refactorizaciones a las tablas / códigos cuando tenga la oportunidad, si puede salirse con la suya.
No pondría comentarios despectivos en el código, ya que lo más probable es que vuelva para atormentarte. En su capa de acceso a datos, podría 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á, puede ser el momento de buscar otro trabajo.
Encuentra un error causado por la desnormalización. Si la base de datos no tiene restricciones adecuadas (y supongo que no lo hará en las circunstancias), tal error existirá. Yo pondría dinero en ello. Si estás usando un rastreador de errores, mira allí. Si no, resuélvelo tú mismo. De cualquier manera, puede demostrar cuánto daño puede causar un error de este tipo, y lo que cuestan para limpiar.
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 hay un montón de código escrito en la base de datos tal como existe ahora.
Sin embargo, sí 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 se pueden corregir simplemente mediante la normalización. El único ejemplo que da es desgarrar su cabello porque tiene que unir datos de tablas separadas cuando un buen diseño hubiera puesto los datos en la misma tabla.
La descomposición de una tabla que debería haberse dejado compuesta no suele ser un error de normalización. Casi todas las fallas en la normalización dan como resultado tablas compuestas que deberían haberse descompuesto. a partir de sus comentarios acerca de asesorarla sobre anomalías de actualización, estoy bastante seguro de que ya sabe lo que pueda enseñarle sobre las formas normales.
La descomposición de las tablas por malas razones, a veces conocida como "hipernormalización", es un sabor diferente del defecto de diseño. Los problemas de programación que surgen de esta falla son muy diferentes de los que surgen de la normalizació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 las posibilidades de cambiar las cosas. Si todos están fuera de forma, 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 se me ocurrió una respuesta simple:
Cuando una base de datos está en uso general, el intercambio de datos ocurre. Eso implica compartir el conocimiento. El conocimiento es poder. Cuando se comparte el poder, ocurre la política.
Esta pregunta podría reformularse para incluir cualquier diseño e implementación, independientemente del dominio del problema.
Es una causa masiva de frustración cuando te metes en una situación como esta. Afortunadamente, no me he metido en esto más de unas pocas veces y he podido evitar en gran medida las partes del SW que se vieron afectadas. O cree una capa intermedia que le permita usar un diseño de base de datos más sano.
Si al diseñador y la gerencia sénior no les importa / entiende, generalmente no hay mucho que hacer. Es lo mismo en cualquier momento que se requiera cualquier cambio que haya existido por un tiempo. Obtener los cambios aprobados por las 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, no sería factible (podría terminar necesitando demasiados cambios en su sw).
Una posibilidad sería, sin embargo, si tiene problemas específicos, como el rendimiento. Si puede demostrar que un mejor diseño de db resolvería estos problemas, podría avanzar un poco.
La forma más positiva sería trabajar con un compañero de trabajo e intentar evolucionar y educar su forma de pensar. Tal vez discutir los errores que ha cometido en el pasado sea fácil para romper el hielo y mostrarle las implicaciones de un sistema mal diseñado.
Si no tiene demasiadas malas experiencias pasadas para ayudarlo, le sugiero que registre cuánto tiempo (tiempo o dinero) llevan a cabo las tareas / defectos específicos para completar. Luego puede producir estadísticas, a todos los gerentes les encantará un gráfico, que se espera que muestre cómo con el tiempo ha aumentado el tiempo requerido para agregar funcionalidad o resolver defectos.
Espero que esto ayude.
Llévelos al sótano. Dales la opción de llevar un sofá grande o 4 sillas pequeñas :)
Mostrar a la alta dirección 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 gran mayoría de los desarrolladores competentes consideran fundamental.
Tratar de ocultar una base de datos mal diseñada detrás de una capa es solo un "truco" y, en mi opinión, debería ser el plan B. Para el plan A, intentaría "escalar" a un nivel más alto.
Como describió, usted 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 director del proyecto si no hay un arquitecto.
Es muy importante mantener sus argumentos con datos bien documentados sobre el impacto que el diseño defectuoso ya tiene en el sistema que está creando. Otros hechos podrían ser problemas conocidos para la base de datos mal diseñada de las comunidades especializadas de db.
No tengo suficiente información sobre su situación, pero esto es lo que generalmente trato de hacer cuando me enfrento a clientes que insisten en una solución técnica mal diseñada.