miércoles, septiembre 14, 2005

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.

6 Comentarios:

At 14/9/05 14:49, Blogger Germán Arduino said...

Coincido mucho con estos comentarios, sobretodo en la "liberación" que se obtiene (de trabajo y problemas) al hacer sistemas SIN tener que pensar en bases de datos relacionales.

Modelar un sistema de objetos, en mi modesto entender, da muchas más posibilidades de modelar la realidad de un dominio (que es lo que siempre perseguimos cuando desarrollamos un sistema) sin tener que congelarla, matarla o aplanarla en filas y columnas.

Saludos!

 
At 19/9/05 11:09, Anonymous Luis Miguel Cabezas said...

Después de leer tu "historia" me quedaban dudas sobre si escribir un comentario a favor o en contra. Sólo quiero dar mi punto de vista:

# Costos de capacitación: La capacitación es algo innerente a los informáticos. El que no sea capaz de capacitarse día a día en distintos modelos, técnicas o sistemas está condenado a morir.

# Costos de desarrollo:
Es posible que sea algo más costoso la primera vez. Pero si se realiza el desarrollo correcto, el código de abstracción de datos puede reutilizarse posteriormente. Muchos sistemas permiten además crear Interfaces gráficos sin necesidad de pasar por ningún lenguaje orientado a objetos: Informix, Access (Ésta se que te gusta), Oracle.


# Rigidez en los diseños: Si el sistema está bien diseñado no tiene porqué haber cambios sustanciales en el modelo. Si los hay es que el sistema es malo (pero no será problema del uso de los dos modelos).

# Problemas de performance: Has obviado técnicas que mejoran el rendimiento de los datos en los SGBD, como las transacciones, procedimientos almacenados o los disparadores, que los hacen casi independientes de los lenguajes.

Sí que se podrían mantener todos los datos en un entorno (mundo) como Squeak (te veo capaz), pero entonces no existiría una independencia datos/lenguaje de programación.

Y si aceptara tu modelo... ¿Podría acceder a tus datos guardados en Squeak desde PHP o Java?

 
At 21/9/05 16:39, Anonymous Fernando Fraga said...

No tiene que ver con este post...

Te mandé al correo la comunicación del congreso Fenda Dixital.

Saludos.

 
At 15/11/05 03:19, Anonymous Anónimo said...

Has utilizado Gemstone/S?

 
At 3/1/06 13:50, Anonymous Anónimo said...

Siguiendo el comentario del anónimo anterior, la opción que falta son las bases orientadas a objetos, que existen hace años y nunca se han impuesto. Porqué? Probablemente por su costo (las comerciales cuestan un huevo, las open-source???... hay alguna?).

Saludos

 
At 19/2/06 01:42, Blogger Asertus said...

Todo es cuestión de montar la http://www.db4o.com con un enlace a Smalltalk, igual que ahora tiene a Java o .NET.

Saludos de otro Smalltalker...

 

Publicar un comentario

<< Principal