En el 2008 empece a trabajar para una startup que tenia un producto para la administración de gobiernos. La cosa con el gobierno es que invierten mucho dinero en infraestructura de TI: licencias, hardware, software a la medida etc. Esto hace casi imposible que acepten una nueva oferta si no pueden reutilizar lo que ya tienen. Con el tiempo la empresa se hizo de varios clientes. Como le hicimos para desplegar el producto usando Oracle, MS SQL o cualquier sistema de base de datos sin cambiar el código? Desde entonces cada vez que me encuentro en un proyecto que esta restringido por una tecnología (como la base de datos) la pregunta vuelve a mi mente.

 Como conseguir independencia de la base de datos

El gobierno es una institución compleja con todas sus reglas y regulaciones. Fue todo un reto hacer el producto suficientemente flexible para adaptarlo a las necesidades de cada cliente. Hasta tenia un motor de scripting! Pero en retrospectiva, creo que esto fue posible por 2 cosas: el uso de un ORM y evitar a toda costa poner lógica de negocios en la base de datos.

Usar un ORM nos permitió usar una representación de datos independiente. Eso quiere decir que todos los datos que necesita el sistema están representados por los objetos, independientemente de como se persistan estos. Esto nos dio la libertad de cambiar de una tecnología de base de datos a otra sin necesidad de cambiar el código. Todo por lo que teníamos que preocuparnos era por cambiar el proveedor, un objeto con el conocimiento de como serializar un objeto a una base de datos. De haberlo deseado hasta podríamos haber escrito un proveedor para guardar en archivos de texto.

Por lo anterior era claro que no era una buena idea poner lógica de negocios en la base de datos. Si lo hubiéramos hecho nos meteríamos en un problema cada vez que migráramos de una base de datos a otra. También es mas difícil de probar.

Encapsulamiento como un atributo del sistema

Ya he hablado del encapsulamiento como un atributo del código. Sin embargo el mismo principio puede aplicarse a un sistema en general. Un requisito es tener una representación de datos independiente, con lo que reducimos el impacto de fuerzas externas (como cambiar las tecnologías de presentación o de almacenamiento). Ese es el propósito de la mayoría de las arquitecturas: hacer que la lógica del negocio sea resistente a cambios externos. En mi experiencia este es un efecto automático cuando seguimos este principio a nivel de objetos.

Acerca de SQL

Algo que siempre me ha llamado la atención es que la especificación estándar de SQL no tiene estructuras de control. Es por eso que cuesta tanto trabajo mover la lógica de un sistema de base de datos a otro: cada quien implementa estas estructuras a su manera. Por que lidiar con esto cuando puedes usar un lenguaje de programación general que ya incluye todo esto? Si el ANSI SQL no lo implementa, por que forzarlo?