martes, 16 de junio de 2015

Asúmelo y sigue

Tienes una base de datos relacional cuyas tablas tienen -todas- identificadores automáticos; no tienes modelada ninguna herencia del dominio; tienes restricciones contextuales que no se representan en el esquema de persistencia (relación uno a uno si una entidad es de un tipo o uno a muchos si es de otro tipo, así que ponemos uno a muchos y ya controlamos desde código que se cumpla), tus VO aparecen, desaparecen y cambian constantemente; la mitad de tu persistencia son meta-datos no relativos directamente al dominio de la aplicación; no tienes borrados en cascada; tus entidades tienen datos que son mutuamente exclusivos... y tantas otras cosas como estas que sé que tienes.

Y yo te pregunto: ¿Para qué quieres un sistema de persistencia relacional como soporte en tiempo real para tu aplicación de dominio si te has cargado, por necesidad y requerimientos, las bondades de sus características? Ve y busca algo que te sirva en vez de que te entorpezca. Quizás un key value store, un column store, un graph store o cualquier otra cosa o combinación de cosas que haga tu vida mas fácil.

De hecho, ya has forzado el sistema relacional y tienes una base de datos documental. ¡Llevas años trabajando con ella y no lo sabías! Eres un pionero en este tipo de tecnologías, y lo mejor de todo es que el código desarrollado actualmente tiene que ser tan consciente de las resticciones de las entidades y sus relaciones que casi te vale directamente para la migración. (Quizás estoy exagerando en esto último, pero si pasas los procesos que tienes a pseudocódigo verás que el flujo de trabajo para trabajar con NoSQL casi casi que lo tienes modelado.)

Deja los motores relacionales para la inteligencia de negocio, los cubos multidimensionales y las bonitas tablas pivotantes que tanto le gustan a los señores con traje y corbata.

1 comentario: