¿Hay alguna esperanza de escribir un buen código sobre una base de datos horriblemente diseñada?

Aquí está mi situación. Uno de los varios programas que heredé recientemente está construido con una horrible base de datos en el backend. Los estimados creadores de la misma aparentemente no apreciaban los conceptos relacionales. Una tabla para cada cliente, nombrada como un ID de cliente único. Ochenta y tres campos crípticamente nombrados. El código es todo procesal con docenas de sentencias SQL en línea concatenadas.

Como no se nos proporcionó una aplicación auxiliar importante que se ejecuta en la misma base de datos, me encargaron recrearla desde cero. Soy un desarrollador exclusivo, que ni siquiera es mi responsabilidad principal, ya que al menos la mitad de mi tiempo lo ocupan las operaciones. Hay un plazo inevitable establecido para 30 días a partir de ahora.

A pesar de mi inexperiencia, estoy seguro de que podría haber diseñado esta base de datos y la aplicación existente mucho mejor de lo que eran, pero realmente no creo que sea realista para mí alterar la base de datos, ajustar la aplicación existente y estar seguro de que no lo hice. No rompa nada mientras necesite crear la aplicación adicional tan rápido.

Así que supongamos que estoy atascado con la terrible base de datos. Al necesitar trabajar con una estructura tan mala, ¿cualquier cosa que escriba que se ajuste a ella solo se sumará a la gran cantidad de deudas técnicas que se guardarán hasta que algo se rompa por completo o se necesite una nueva funcionalidad? ¿Cómo podría abordar esta situación y obtener algo bueno además de una aplicación con suerte funcional?

editar: en caso de que alguien esté interesado, terminamos desechando esta horrible base de datos y la aplicación que se ejecutó en ella. Subcontratamos la creación de la aplicación auxiliar (no participé en la configuración) a dos contratistas diferentes que terminaron cayendo sobre nosotros, sin lograr nada. Terminé teniendo que apresurar un truco horrible y parcialmente funcional de una solución en tres días que todavía está en uso hoy.

Hay esperanza, pero es una batalla cuesta arriba, especialmente si nadie se da cuenta de que el diseño de la base de datos es horrible. Puede intentar abstraer la maldad con capas de abstracción, pero es probable que no valga la pena la batalla.

Mi consejo sería crear suficientes abstracciones sobre la base de datos para que la aplicación en sí misma esté limpia y correctamente diseñada; de esa manera, si alguna vez puede arreglar la base de datos, la aplicación no se verá afectada ya que no le importa cómo se diseñó la base de datos.

Este es el enfoque que normalmente uso cuando trato con una base de datos que está en su lugar y, la mayoría de las veces, diseñada con cero pensamiento. Algunas aplicaciones de elección de los patrones de repositorio o puerta de enlace, con algunas capas de servicios para comunicarse con la puerta de enlace / repositorio, deberían ayudar a poner en cuarentena el diseño deficiente.

Cree una capa de interfaz que maneje todas las cosas de la base de datos y luego escriba su aplicación para interactuar con eso. En el caso de que la base de datos se "arregle", simplemente reemplace / actualice su "interfaz". Este enfoque me ha ahorrado un montón de tiempo al tratar con una base de datos incorrecta o una base de datos que estaba alimentando otras aplicaciones y con la que no podía meterse.

Ouch ... ¿Heredaste un desastre de pesadilla, tienes 30 días para que sea utilizable en tu organización y la mitad de tu día está ocupado en tareas de operaciones?

Estoy seguro de que podría refactorizar, pero ciertamente no en ese período de tiempo.

Para responder a su pregunta, no creo que pueda escribir un buen código en dicho diseño. La deuda técnica ya es demasiado. Si fuera usted, piratearía las funciones que pudiera y presionaría para una refactorización completa en una fecha posterior cuando tenga más tiempo y personas en su equipo para abordarlo mejor.

Solo tenga cuidado al presionar para refactorizar. A veces, un superior tomará la decisión de comprar un código fuente de productos y derechos de propiedad y no querrán pensar que desperdiciaron completamente su dinero en la basura. Este fue el caso para mí en un trabajo que tenía. Desafortunadamente, los gerentes toman decisiones sobre la compra de software como este y nunca obtienen participación técnica para evaluar lo que están comprando y ver si es mantenible y tiene una gran cantidad de deuda técnica. En este caso, la mala decisión es política y presionar por la refactorización puede poner en riesgo su trabajo.

Las bases de datos se pueden refactorizar como cualquier otro código. Arregle la parte que está afectada por el código que necesita para escribir y escribir pruebas para asegurarse de que nada más se rompa. Haga un poco a la vez como cualquier otra refactorización. Hay un buen libro sobre refactorización de bases de datos que podría ayudarlo a comenzar a limpiar el desorden. http://www.amazon.com/Refactoring-Databases-Evolutionary-paperback-Addison-Wesley/dp/0321774515/ref=sr_1_1?ie=UTF8&qid=1307025831&sr=8-1

También hay otros, pero personalmente he leído y trabajado con las técnicas de este.

Y no olvide que puede reestructurar la forma en que necesita consultar la base de datos creando vistas para realizar el desagradable trabajo de transformación en una estructura que sea más fácil de consultar.

Para obtener el mayor rendimiento de su inversión, cree vistas actualizables para restaurar algunas de las "relaciones" y para proporcionar nombres de columna más significativos.

Una posibilidad sería configurar una segunda base de datos que esté estructurada (al menos más cerca) de cómo le gustaría, y configurar la replicación entre las dos bases de datos. Luego, puede escribir su código en la nueva base de datos y aún dejar intacta la base de datos (y la aplicación) existente, para que la traten cuando tenga más tiempo.

A decir verdad, todavía está abierto a muchas preguntas si puedes hacer eso en ~ 15 días de trabajo. En particular, es probable que dependa de si necesita una replicación bidireccional (es decir, su nueva aplicación realmente actualizará los datos) o solo de una manera (su nueva aplicación simplemente permite que las personas vean los datos). El último caso es (por supuesto) dramáticamente más fácil de tratar.

Si necesita una replicación bidireccional, es probable que no sea suficiente tiempo para hacer el trabajo. En particular, la replicación bidireccional que implica transformar sustancialmente la estructura nunca es trivial, y las herramientas disponibles a menudo lo soportan bastante mal (por ejemplo, tener que escribir a mano todo el SQL para todas las transformaciones de datos en ambas direcciones).

Si solo necesita una vía, es justo en el punto en que podría bordear la posibilidad de ser posible. También dependerá un poco de si se le permite gastar dinero o no: hay bastantes aplicaciones de almacenamiento de datos que están destinadas exactamente a este tipo de tareas que probablemente lo hagan un poco más rápido y fácil administrar, pero la mayoría de ellos no son baratos.