jueves, 2 de abril de 2009

Deja de hibernar y despierta de una vez!

Me hago eco de este artículo: "Good Advice on Keeping Your Database Simple and Fast".

Independientemente de si nos parece bien, mal o regular todo lo demás, de si creemos en SimpleDB y S3 o no... e independientemente de si todo este rollo del Cloud mola pero no te aplica porque tus problemas son otros, tú trabajas en un sistema de información interno...

...El primer párrafo del artículo es para enmarcarlo, y traduzco literalmente:
Mantener una base de datos simple y rápida es muchas veces complicado si se usan frameworks de alto nivel como (...) o tecnologías de persistencia de objetos en Java como HIBERNATE. Hay una gran cantidad de "magia" que ocurre fuera de tu vista sobre la que no tienes ningún control. Si tienes que escalar tu aplicación, generalmente son estas tecnologías para acceder a bases de datos relacionales las que se convierten en el cuello de botella tanto de rendimiento como de escalabilidad. (...)

¡Algo sensato! ¡Por fin! Por favor que vuelvan los tiempos del JDBC crudo (dentro o fuera de un EJB). Y no necesariamente implica perder el tiempo en codificar como un mulo.

Ya en el año 2001 en mi anterior empresa ideé y lideré un sistema que llamamos "BeanBuilder" para generar todo tipo de código a partir del esquema de base de datos. Y no sólo me refiero a los EJB con altas/bajas/modificaciones/consultas/filtros/paginación, sino incluso llegamos a generar operativas completas con sus JSP de listado y de formularios de alta en base a plantillas. Para que sirvan como base para modificarlos, ampliarlos, etc. Pero siempre con control sobre el código generado porque generábamos código Java.

Y allá por 2004 el sistema era realmente complejo, admitíamos tomar como punto de partida joins entre varias tablas y generar lo apropiado... Teníamos un formulario en el que elegías el tipo de framework que debía utilizar el código generado (¿EJB o framework propio con POJO? ¿JSP o XSLT? ¿Struts o nuestro framework propio?). Vamos, una herramienta para cualquier proyecto que abordáramos...

Es decir si el objetivo es ahorrar esas horas de desarrollo "que no aportan valor" pero mantener el control sobre lo que potencialmente te va a dar problemas.

No preguntéis el motivo, pero quedó en vía muerta. Si volviera a quella época hubiera lanzado un proyecto Open Source en toda regla...

¡Es hora de despertar de la "hibernación" en que estos arquitectos de salón nos han metido!

3 comentarios:

navarros dijo...

ah! que tiempos.....echando un poco más la vista atrás me acuerdo incluso de CShop.
Ciertamente no era tan avanzado (ni muchiiisimo menos) que BeanBuilder ya que era una jerarquía organizada de clases pero estaba tan bien construída que nos permitia crear una aplicación con 20 entidades de información en escasamente 10h.

...que tiempos ;)

angelborroy dijo...

Decía esta mañana (puto autenticador de OpenID) que algo de "vuestra" filosofía se me habrá pegado...

El año pasado diseñé un sistema que tenía que responder peticiones en "tiempo real" (o sea, muy rápido). El tema es que para la capa de base de datos elegí Spring JDBC (que puede usarse prácticamente como jdbc si no te dejas embaucar por las paranoias) y los DAOs se generaron a través de un par de clases Java.

Hasta la fecha no ha habido en el sistema ningún error "extraño", "indetectable" o "irreproducible" relativo a la capa de acceso a datos :)

serverperformance dijo...

Com dirían Les Luthieres, cualquier tiempo pasado fue... pasado.

Y manda huevos que lo diga yo, que precisamente estoy en pleno viaje astral...