17/03/2008
17/09/2008
11/06/2008
21/02/2008
10/03/2008
26/03/2008
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.
¿Sigue teniendo sentido hoy en día almacenar un modelo de objetos en tablas relacionales?
Pues oiga, francamente no. Pero, y ese es el gran pero, ¿dónde está el equivalente al SQL para manipular datos en esos objetos? La primera respuesta que se te viene a la cabeza es ¿y para qué hace falta?
No es incorrecto hacerse la primera pregunta. Después de todo, las BBDRR deben su éxisto a que el lenguaje SQL se usa, con pequeñas variaciones en todas. Pero es que encima es muy fácil de usar a nivel básico, hay montones de herramientas a su alrededor que lo utilizan (el infame Crystal Reports, Access, etc) Como la entrada al SQL es muy barata, eso genera mucho público. Y sin darte cuenta, has respondido a la segunda pregunta.
Técnicamente podríamos prescidir del modelo relacional, pero entonces tendría que haber algo que permitiera explotar nuestros datos de forma estándar, accesible, fácil, rápida e interactiva. SQL lo es.
Menudo deja-vú... habre leido esta discusión media docena de veces... o el mundo ha dado un giro radical desde la ultima vez o la conclusion es la misma, asi que, con permiso, me lo salto. :)
¿Teneis idea del infierno que es mantener una base de datos orientada a objetos a medio plazo? Son lentísimas, cuando quieres contratar a alguien que sepa de qué va el tema, primero no lo hay en España, luego es muy caro y tercero lo necesitas casi de por vida. Apenas hay herramientas para gestionarlas -en comparación con las relacionales- y dependen de un montón de decisiones que se han hecho en el momento (y en serio, todos sabemos que realmente hay 4 personas que sepan modelar de verdad)
Las bd relacionales tienen su respaldo matemático y mucha documentación. Con las orientadas a objetos... bueno, buena suerte :)
Sobre tu artículo, deja las drogas. ¿iBatis un mapeador relacional? Anda ya. ¿JDBC más rápido? Depende. Si tienes 1000 horas para la persistencia y con 200 lo tienes ya mapeado con Hibernate, JPA, TL o similares, pues te quedan 800 para optimizar las partes que verdaderamente van lentas (que suelen estar muy acotadas) Además has ganado una facilidad de crecimiento de la aplicación que simplemente no tiene precio en tiempo y bugs. Y al final, para las cosas que son procesos come-tiempo acabarás usando todos los recurcos específicos de tu motor de bases de datos por lo que por estar simplemente orientada a objetos no te va a ayudar mucho.
En una empresa hay además factores externos: ¿tu proyecto es el único que accede a esos datos? ¿La gente de sistemas sabe mantener ese modelo orientado a objetos? ¿Las herramientas que interactuan con esa información (generadores de informes, extracción, etc) están preparados para trabajar con bases de datos orientadas a objetos? ¿Y tus DBA's? Los modelos relacionales, cuando están hechos tan sólo un poco bien, no suelen cambiar estructuralmente, sólo localmente, sobre todo crecen. ¿Puedes decir lo mismo del modelo de tu aplicación? Y una pregunta importantísima: ¿asumirías tú la responsabilidad de todo esto adoptando una base de datos orientada a objetos porque crees que los beneficios compensan a los riesgos en esta época con mapeadores O/R tan maduros?
No te confundas: me gustaría llegar a que sea factible usar bd oo pero a día de hoy no parece muy realista.
Cuña publicitaria: Estoy buscando la posibilidad de trabajar desde Vietnam (Ho Chi Minh City) Si alguien conoce a alguna empresa que tenga presencia en VN o que permita trabajr en remoto, le estaría agradecido de verdad (juan.medin en gmail.com)
Estoy de acuerdo con la planteado con juanmp, la verdad que las bases de datos orientada a objetos, aun le falta madurar, los factores externos y que son requerimientos técnicos que no podemos obviar en la mayoría de los proyectos ( por no decir todos ), nos impiden utilizarlos; i .e integraciones con otros sistemas, mantener la base de datos, herramientas de informes, etc....
Las base de datos orientada a objetos, serán el futuro pero en estos momentos no existe la plataforma para realizar un proyecto de gran envergadura.
Una pregunta relacionado al tema, La nueva especificación de JDBC 4.0 no ayuda en gran medida a facilitar el trabajo directamente con las bases de datos y en gran medida a reducir el uso de los framework de persistencia?.
Gracias.
Que bonito es hablar por hablar. Suena todo muy bien hasta que trabajas con Versant, que es lider en su categoria. Su precio, soporte, y consultoria es carisimo. En internet hay cero información. Nadie conoce Versant. Tiene defectos cuya única solución es comprar la siguiente versión del producto. Su número de instalaciones se reducen a "decisiones" como comentan arriba, y a aplicaciones legacy. Tras trabajar en la empresa X evaluando bases de datos de alto rendimiento me "sorprendio" ver a un consultor de Versant en la empresa Y que mencionaba a X como cliente.
Casos habra donde convenga usarlo pero considera primero si un cluster de bases de datos en memoria no puede hacer el trabajo. Ya de entrada pocos proyectos hay en españa que se podrian permitir lo que cuesta. Las telecos por su parten usan todas bases de datos en memoria.
Por cierto, curioso el giro de Versant a JDO y pateticas sus mentiras sobre hibernate.
Veamos:
Ya ha pasado bastante agua por este río y hoy las cosas parecen bastante mas claras que antes.
1ero) No me cabe duda que algún día se realizará la persistencia de los objetos Java directamente contra una interfaz Orientada a objetos que brindaran las bases de datos. Lo cual no significan que las bases de datos estarán orientadas a objetos, sino que brindaran una interfaz (espero que sea JDO o algo parecido)
2do) Hoy por hoy las bases orientadas o objetos propiamente dichas han perdido el rumbo y solo sobreviven en pequeños nichos de mercado donde se necesita un acceso rápido a los objetos generalmente navegando un grafo de asociación de objetos(telecomunicaciones, empresas de servicios en su área técnica, generalmente para representar la conectividad de objetos).
Sobreviven con altura: ObjectStore y Objectivity, tal vez DB4O.
Sobrevive con problemas: Versant.
3ro) El futuro?: No lo se , es difícil de prever , supongo que depende de alguna de las grandes empresas (SUN, IBM, ORACLE) que den el primer paso.
Que me gustaría? Pues que la gente de JPOX lograra algún acuerdo con SUN y se pudiera incorporar de alguna forma en la distribución de MySQL, cuanto mas integrado mejor. Supongo que con el tiempo se podría tener una interfaz JDO que accediera a en lo profundo de las apis de MySQL (es decir: no solo utilizar el lenguaje SQL para consultar el motor) para obtener el máximo rendimiento.
Mmm... ningún comentario sobre SimpleDB o CouchDB, BBDD orientadas "a documento"?
venkman: jeje, si yo lo comento en el podcast que hablamos de esta noticia pero todavía no lo hemos públicado :P
Couch DB me parece especialmente interesante, y ya que estamos en javahispano otro API que puede tener mucho que decir en este tema es el Java Content Repository (JSR-127) del que por el momento se habla poco pero puede tener muchas cosas que decir en el futuro. (algo interesante sería implementar JCR usando como medio de almacenamiento CouchDB, encajan como anillo al dedo)
Para algunos tipos de aplicaciones (orientadas a documentos fundamentalmente) suponen un gran avance, por ejemplo una web como javahispano o similares se podrían beneficiar enormemente de este enfoque. Las noticias serían un nodo/documento con algunas propiedades (autor, fecha, comentarios...) la forma de extraer/insertar documentos sería mucho más "natural" que en un BD relacional y como regalo te llevas soporte para versiones de documento, busqudas full-text, listeners para notificiones de cambios en los documentos etc,etc...
Hola!
La persistencia automatica de objectos ya es un hecho en otros lenguajes como Lisp. Que incorpora casi todos los paradigmas de programación: orientado a objetos, funcional, etc...
Un ejemplo:
http://www.franz.com/products/allegrocl/
Las soluciones más populares (Java) no siempre son las mejores.
Saludos
Una solucion propietaria para un lenguaje en concreto, ¡Que bien! Ya podemos tirar todas las herramientas badadas en estandares e independencia de BDD o lenguaje de programacion, que son un rollo y no valen para nada. Menos mal.
Hola,
¿Siguen siendo las bases de datos relacionales la mejor opción?: Sí
Saludos,
Francesc Rosés
¿Siguen siendo las bases de datos relacionales la mejor opción?
Las bases de datos relacionales son LA ÚNICA OPCIÓN (afortunadamente)
La situación informática actual es un caos! 50 maneras de hacer lo mismo.
La informàtica y concretamente la programación necessita una rebolución!!
Generación automática de interfaz grafica! Persistena automática! Utilidades de migración. Programación usando reglas e las que se especifica el "que" y no el "como"....
Yo creo que la mejor opcion es un sistema experto basado en inteligencia artificial, con un interfaz de realidad virtual (con su casco y el dataglove, claro), que se programe a si mismo, claro!, en un lenguaje visual de quinta generacion.
Firmado: pernalonga
Con respeto al "Anonimo cobarde" que escribio
"Las bases de datos relacionales son LA ÚNICA OPCIÓN (afortunadamente)"
es obvio que esa persona no tiene mucha experiencia en informatica, como no es capaz de aceptar que hay muchas opciones y TODOS tienen sus ventajas y desventajas. Que sorpresa que la persona no queria registrar antes de poner ese comentario o sus sus compañeros de trabajo se verian como inteligente sea. Desgraciadamente hay muchas personas en informatica asi. Si esta persona quiere registrar y tener un debate inteligente sobre las muchas formas de persistencia estaria dispuesto a participar. Ya en tus manos señor anonimo ...
hay muchas opciones y TODOS [sic] tienen sus ventajas y desventajas
¿Sí? A ver, díganos qué opciones hay, además de las bases de datos relacionales.
Que sorpresa que la persona no queria registrar antes de poner ese comentario o sus sus compañeros de trabajo se verian como inteligente sea [sic, sic, sic...]
¡hoygan! ;-)
La unica opcion inteligente seria bases de datos de ODBMS. No se hace falta mucha inteligencia saberlo
No. La unica opcion inteligente seria persistencia a una base de datos de XML
La "única opción inteligente" es mantener la mente abierta a la posibilidad de existan otras opciones inteligentes. Por favor, creced un poco y discutid los méritos o inconvenientes de las cosas con un poco más de madurez. Gracias.
Escribe tu comentario