Buscar
Social
Ofertas laborales ES
viernes
mar072008

¿Siguen siendo las bases de datos relacionales la mejor opción?

La solución a la persistencia de datos ha estado tradicionalmente ligada a las bases de datos relacionales. La transición a la programación orientada a objetos, que bien podríamos dar por finalizada, no ha cambiado en absoluto este hecho.

Cuando realizamos aplicaciones, la mayoría organizamos nuestro modelo en una jerarquía de clases y luego garantizamos su persistencia en una base de datos relacional. Las diferencias entre el modelo de objetos y el relacional causa algunos problemas con los que los desarrolladores estamos acostumbrados a lidiar.

Uno de ellos es la forma de acceder a los datos. Por una parte tenemos nuestros grafos de objetos, que acostumbramos a utilizar para la "navegación" a través del modelo:

employee.department().manager().salary();  
 Y por otro lado tenemos las consultas SQL para manejar el modelo relacional:
SELECT e2.salary FROM
employee e1, employee e2, department,
WHERE
e1.id = current_employee_id
AND
e1.department = department.id
AND
department.manager = e2.id

Con el tiempo muchos desarrolladores han renegado de incrustar sentencias SQL en su código Java, pasando a emplear mapeadores objeto-relacionales como iBatis, Hibernate, TopLink, etc. Estos frameworks han permitido delegar el problema de la falta de concordancia objeto-relacional en una librería externa que nos hace casi transparente (casi) la traducción de un modelo a otro.

La mejora de productividad que aporta el mapeo objeto-relacional tiene su contrapartida en el apartado de rendimiento. Con una solución más clásica como es el uso de consultas SQL a través de JDBC obtenemos un rendimiento mayor que el que obtendremos poniendo por medio un Hibernate, por ejemplo.

Algunos críticos de este tipo de frameworks no los critican solamente por su rendimiento sino porque consideran que no es el enfoque correcto a la falta de concordancia entre el modelo de objetos y las bases de datos relacionales. 

Debería considerarse la posibilidad de almacenar nuestros objetos en una base de datos orientada a objetos, librándonos del problema que pretenden solucionar los frameworks de mapeo objeto-relacional. 

Estas bases de datos tienen un rendimiento mayor a las relacionales, ya que los datos se guardan de una forma muy similar a la que tienen nuestros objetos en memoria. Esto provoca que el mayor nicho de mercado para estas bases de datos sea el de dispositivos móviles, donde bajar el consumo de recursos es prioritario y no hay un DBA que pueda optimizar y mantener la base de datos.

En el lado opuesto, en el de las aplicaciones que requieren poder escalar de forma masiva, tenemos soluciones para la persistencia que tienen mucho que ver con bases de datos orientadas a objetos. A poco que indaguemos en tecnologías del ámbito del grid computing como GigaSpaces o Coherence, veremos que tienen mucha relación con las ODBMS.

Creo que sería interesante un debate sobre el tema en JavaHispano.

¿Sigue teniendo sentido hoy en día almacenar un modelo de objetos en tablas relacionales?

Os dejo un enlace a un artículo de la competencia (InfoQ) en el que se exponen distintos puntos de vista: Java Object Persistency: State of the union.

 

 

viernes
mar072008

Mapa de Usuarios de JavaHispano en GMaps

A petición de mrmx -y dado que Frappr simplemente no me funciona- he creado un mapa de usuarios de JavaHispano en Gmaps.

Apuntaos si queréis. O si sabéis de un sitio de mapas mejor que Frapper y que no sea necesario registrarlo, decídmelo y lo creo ahí. En ese caso, no votad negativamente esta noticia.

jueves
mar062008

Actualización 1.5 de OpenSwing, framework libre para el desarrollo de aplicaciones Swing

OpenSwing es un framework para el desarrollo de aplicaciones swing, tanto para aquellas que no se comunican con una base de datos como para aquellas aplicaciones de dos o tres capas cuyo front end es una aplicación de escritorio. El framework incluye un conjunto de componentes gráficos implementados en Swing orientados a la visualización de datos entre los cuales hay componentes para mostrar cantidades de dinero, grids, un componente híbrido entre un árbol y un grid, calendarios, diagramas de Gantt y un largo etcétera.

OpenSwing también cuenta con una librería para el desarrollo de la capa de acceso a datos y (para las aplicaciones de tres capas) la lógica de negocio, así como una librería que se encarga de simplificar la comunicación con el servidor. También cuenta con componentes para visualizar documentos PDF y Excel. El framework se distribuye bajo licencia LGPL y cuenta con abundante documentación entre la cual se incluyen varias aplicaciones de demostración.

Noticias pasadas del Web site:

  • Added grid exporting feature when combining OpenSwing to Spring framework.
  • Added new property to ListControl in order to provide a "check-box list": "showCheckBoxes" property allows to show a check-box for each item to select.
  • Added "NoLogger" class to avoid to log any message.
  • Added some new properties and utility methods to TreePanel in order to provide a "check-box tree"
  • Improved check-box control and check-box column by adding a third optional state: null, that can be activated through new property "allowNullValue", i.e. now a check box can be selected, deselected and set to null.
  • Improved AboutDialog by supporting HTML based text.
  • Added LinkButton component, used to show a link with an ActionListener binded.
  • Added support for tif/bmp/png image formats to TreePanel/ImagePanel/ClientUtils.getImage(), when combined with JAI Sun library.
  • Added support for tif/ico/bmp/png/pic/pcx image formats to TreePanel/ImagePanel/ClientUtils.getImage(), when combined with JIMI Sun library. See "Installation info" section for instructions about how to use it.
  • Added an iconifable window (IconifableWindow class) that can contains any type of graphics component.
  • Moreover, a set of iconifable windows can be grouped together to realize an "Outlook like" set of panes through new IconifableWindowContainer class.

 

Algunos acoplamientos:

Home page: http://oswing.sourceforge.net

Demo: http://oswing.sourceforge.net/demo10/demo10.jnlp 

JAllInOne demo: http://www.hostingjava.it/-carniel/jAllInOne.jnlp  (account: guest/guest)

 

jueves
mar062008

Máquina Da Vinci ¿tras los pasos de .NET?

Sí, es verdad, el título busca provocar. Pero en el buen sentido, para animar a que surja un debate interesante. Siguiendo una noticia publicada en planeta javaHispano en la que se comenta que Jonathan Schwartz afirma que están pensando en quitar la J de JVM, he llegado, por medio de un enlace, al conocimiento de la existencia de un proyecto llamado Máquina de Da Vinci de Sun. Se trata de una tecnología que permite mejorar el soporte para la ejecución de múltiples lenguajes en la JVM. En el fondo, supone un cambio sustancial en la actual JVM y de algún modo una aproximación a la filosofía de .NET. ¿Créeis que eso favorecerá a Java? ¿Créeis que realmente se llevará a cabo y se logrará algo semejante a lo que ha hecho Microsoft pero con un soporte de verdad para Linux y Solaris?

jueves
mar062008

¿Por qué no hay JUGs en España?

Recientemente, Daniel Latorre puso esa pregunta en su miniblog de jaiku (sorry no es público, necesitas tener cuenta en dichos servicio para verlo).. como podrán ver en el mapa de JUGs de Sun, España se encuentra vacío.

Me parece que el último JUG de este país era el de Cataluña (AUJAC) que se disolvió el año pasado y antes de que lo pregunten, Javahispano es un JUG virtual, esta pregunta va más dirigida a JUGs locales, aquellos de reuniones todos los meses/semanas para compartir experiencias y cervezas..

Java es un lenguaje con bastantes desarrolladores en este país, además de que la base de programadores crece día a día, ¿qué sucede, por qué no hay JUGs en España? 

¿Será que la gente simplemente no tiene tiempo entre tanto trabajo para organizarse o que Java a pesar de seguir siendo usado ya no es emocionante como para hacer reuniones con tus colegas y discutir sobre él?