La magia del Smalltalk: Capítulo 12 - ¡Basta ya de las bases de datos relacionales!

Hace tiempo que no discuto con mi esposa, así que ando con un poco de ganas de pelear y voy a sacar de la galera uno de los tópicos más controversiales en lo que respecta al desarrollo de software:

El (ab)uso de las bases de datos relacionales.

No quiero entrar en una de esas discusiones estériles que tanto nos gustan a los programadores. Ya gasté muchísimo tiempo en discusiones tipo: Vi -> Emacs, Linux -> FreeBSD, GPL -> Licencia MIT, GNOME -> KDE y, sobre todo, en elRestoDelMundo/Smalltalk.

De la misma forma en que nadie puede decir que un paradigma de programación sea mejor que el otro, no podemos decir que el paradigma de objetos sea mejor o peor que el paradigma relacional.

No dudo que las bases de datos relacionales sean útiles, pero de lo que estoy seguro es que la mayoría de los usos que se les da a las bases de datos relacionales son incorrectos, incómodos e ineficientes.

Excepto por algún loco que condene el paradigma de objetos, hay un consenso bastante amplio en considerar que el modelado con objetos mejora en el desarrollo de software. Alcanza con ver como los lenguajes de moda se van pareciendo, cada vez más, a Smalltalk. Si no lo creen, analicen la linea sucesoria: C++ -> Java -> C# -> Python -> Ruby o piensen en los cambios que sufrieron el Basic (en su paso a Visual Basic o Gambas) o el Pascal (en su paso a Delphi y Oberon).

El problema se nos presenta porque la mayoría de los proyectos de desarrollo de software, que usan alguna forma del paradigma de objetos, usan una base de datos relacional como mecanismo de persistencia de los datos.

Ese mundo híbrido en el que nos toca (sobre)vivir tiene muchos inconvenientes. Hablemos de algunos:

• Costos de capacitación: Todas las personas involucradas en el desarrollo tiene que poder expresarse fluidamente en dos paradigmas diferentes y cambiar, en la forma de pensar, entre el álgebra relacional y los objetos durante el proceso de desarrollo.


• Costos de desarrollo: No es raro encontrar que el costo de desarrollo del mapeo objeto/relacional llegue a ser un porcentaje importante del desarrollo. No es raro encontrarse con sistemas que sólo piden datos a los usuarios para meterlos en tablas.


• Rigidez en los diseños: Los cambios en el diseño del sistema son más caros ya que hay que hacer los cambios en 2 modelos diferentes, y en el mapeo entre los modelos. No es raro encontrarse con jerarquías de clases terriblemente planas con tal de evitar problemas en el mapeo.


• Problemas de performance: Las técnicas para mejorar los tiempos de procesamiento y respuesta son diferentes entre el modelo relacional y el modelo de objetos y, para peor, muchos de las técnicas que mejoran la performance en un modelo, producen el efecto contrario en el otro. Eso sin hablar del tiempo (de ejecución) que implica hacer el mapeo objetos/relacional todo el tiempo. Ciclos del tipo: Leer datos de la DB -> instanciar objetos con esos datos -> mostrar los objetos para su modificación -> pasar los datos de los objetos a la DB no son excepciones.

Estas son algunas cosas que, creo, deberíamos preguntarnos los programadores:

• ¿Cuantas tablas, en las bases de datos relacionales, no tienen más que unos pocos cientos de registros?


• ¿Y cuanta duplicación genera el modelo relacional? o más concretamente: ¿Cuanto ocupan, en las bases de datos relacionales, 1000 clientes que se llamen todos “Juan Pérez”?


• ¿Cuantos objetos entran en los 512Mb de RAM que tiene mi notebook?

---

Entonces, ¿Cuál es la alternativa?

Por supuesto que no hay sólo una alternativa, pero me gustaría detenerme sobre una de ellas. La que más me gusta, la más simple, la más barata y que puede usarse en un porcentaje muy alto de proyectos:

Use the RAM memory, Luke!
(¡Usá la memoría RAM, Luke!)

La solución es muy simple: Guardar todos los objetos en la imagen de Smalltalk o, si no usan Smalltalk, la solución sería tener todo en memoria y deserializar/serializar al arrancar/detener el sistema.

Si, ya se que parece una solución naive y que me estoy olvidando de cosas muy serias como acceso concurrente, seguridad, políticas de lockeo, etc. En realidad no me estoy olvidando de esos temas, sólo les digo que con el tiempo de desarrollo que se van a ahorrar si no usan bases de datos relacionales les va a sobrar para atender a todos esos puntos.