18/05/2009
02/06/2009
18/06/2009
Cristian González Losada
Analista-programador en Nevian Sistemas
La solución a la persistencia de datos ha estado tradicionalmente ligada a las BBDD relacionales. La transición a la POO, que bien podríamos dar por finalizada, no ha cambiado en absoluto este hecho.
Las diferencias entre el modelo de objetos y el relacional nos causa más de un problema a los desarrolladores. Estamos obligados a crear y mantener dos modelos (el de objetos y el relacional), así como a desarrollar clases que transformen nuestros datos de un modelo a otro.
Con el tiempo muchos desarrolladores han renegado de incrustar sentencias SQL en su código Java, pasando a emplear mapeadores O-R como 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 la traducción de un modelo a otro.
Algunos críticos de este tipo de frameworks consideran que no es el enfoque correcto para solucionar el problema. Debería considerarse la posibilidad de almacenar nuestros objetos en BBDD orientada a objetos, librándonos del problema que pretenden resolver los frameworks de mapeo O-R.
Considero que el que estemos dejando de incrustar SQL en nuestro código en favor de distantas APIs de persistencia, facilitará una futura transición a este tipo de BBDD, cuando estos sistemas maduren y nos hayamos puesto de acuerdo en un lenguaje estándar de consulta para el modelo de objetos (que podría ser algo similar a LINQ o HQL, por ejemplo).
Etiquetas: otro, opinion, solo, programadores
FYI: The Third Manifesto
Solo plantear un par de dudas de un total ignorante de las bases de datos orientadas a objetos
No, no tiene ningún sentido, es un engorro de los grandes.
¡Queremos BBDD OO YA!
He estado probando Gemstone, la versión de GLASS. Ahí el almacenamiento de objetos es persistente tal cuál, de forma, a mi gusto, mucho más transparente que db4o, por ejemplo. Y creo que, para los sistemas grandes y masivos, por ahí irá el futuro.
Respecto a otros sistemas más modestos, o para "colecciones" (antes tablas), de objetos pequeñas, el enfoque futuro incluso iría más por "persistencia de memoria", tipo "imagen" Smalltalk, donde todo estará en RAM (la RAM de ahora es mayor que muchos discos duros de hace apenas años), con respaldos (dumps) definidos para recuperaciones de caídas (según necesidad o no de transacción ACID). Una implementación sencilla de esto para Java es http://www.prevayler.org/wiki/.
En cualquier caso, respondiendo a la pregunta, quizás las alternativas no ofrence lo "suficiente" aún como para serlo en grandes entornos corporativos, pero haberlas haylas... quizás baste con que Gemstone sea comprada por IBM o que Oracle haga una versión cara de DB40...
Saludos
Hola, mi opinión es la siguiente:
Hacer sqls para meter datos en la BD es un atraso. Aunque no he tenido la posibilidad de utilizar un framework tipo hibernate para hacer la persistencia, me parece que es "lo menos malo". Estoy a favor de la BD orientados a objetos de verdad, hace muchos años use una BD orientada a objetos, en la que le pasabas los bean a la api de la BD y los guardaba, y los recuperas por la PK de la tabla con toda su relación. Lo malo? Era más lenta que el caballo del malo, y solo le pedía 10 peticiones a la vez!!!! con muchas conexiones no se podría utilizar.
De hecho creo que el SQL desaparecerá, ya que cada BD usa su propio SQL que no es portable. Lo que ocurre es que existen muchos tios que les pagan por hacer sqls del carajo y procedimiento almacenados infumables, etc, etc, etc.
salu2
perdón por no logearme, soy el que empieza diciendo "Hola, mi opinión es la siguiente:"
Que curioso que todavía se sigue discutiendo usar Base de datos orientadas a objetos cuando el mercado se está moviendo a un modelo mucho más ágil donde el desempeño es lo más importante y a usar bases de datos no relacionales basadas en BigTable. Veo mucho más factible que terminemos usando este modelo (al menos en aplicaciones empresariales, que no en aplicaciones móviles) en el futuro cercano que cambiarnos a usar BD orientadas a objetos.
Lo del SQL para almacenar los datos es una confabulacion judeomasonica de gente que no quiere aprender Java, seguro.
Lo mejor es la transparecia total, esto de tener que decidir como guardar los datos de la forma mas adecuada es un engorro. Inventado por gente que no tenia trabajo y se inventaron eso de DBA, seguro. Lo mejor de lo mejor, que directamente de mi lenguaje de alto nivel yo diga "guarda" y automaticamente se decida todo por mi y se tengan en cuenta todos casos posibles, optimizaciones...
Además, lo importante es mi programa y con que tecnologia y metodologia lo implemento, los datos son lo de menos, total... que van a pintar sin mi programa. Y como absolutamente todos los programas se hacen, y se haran en un futuro, orientados a objetos, lo mejor es directamente guardarlos así.
Lo del rendimiento, bah, un mito, si toda mi arquitectura es mas orientado a objetos, por definicion es mejor. La historia de la BDD orientadas a objetos lo demuestra totalmente.
La misma cantinela otra vez... digo... revolución ya!
Disclaimer: Esta mañana no se si tome la pastilla roja o la azul :)
Bueno, pues yo sí tengo bastante experiencia con Hibernate (un ORM) y la verdad es que me parece una auténtica maravilla. Esta discusión me recuerda mucho a la de si implementar ciertas cosas a nivel de base de datos con lenguajes como perlsql.
Para mí la base de datos debe ser una base de datos y punto. Reconozco que nunca he usado una base de datos orientada a objetos pero me imagino que tendríamos problemas al usarla desde cualquier lenguaje no orientado a objetos como puede ser C. Y siguiendo con el ejemplo de implementar lógica de negocio con perlsql, supongo que tendríamos problemas a la hora de migrar nuestra aplicación a otra solución que no soporte ese lenguaje de script o que lo tenga pero con sus propias particularidades.
Siempre he pensado que el fabricante es especialista en crearnos falsas necesidades que además sirven para atarnos a su plataforma: ¿por qué implementar lógica de negocio a nivel de base de datos si eso mismo lo puedo hacer desde el propio lenguaje de programación? ¿por qué decantarnos por una orientación a objetos si ese paradigma lo podemos elegir desde nuestro propio lenguaje de programación (aunque sea recurriendo a marcos de trabajo como Hibernate)?
Ojo, que creo que lenguajes de script como perlsql puede ser una herramienta fantástica para los administradores de bases de datos. Pero claro, de ahí a utilizarlos cuando estamos haciendo un desarrollo... Creo que no suele ser muy común desarrollar aplicaciones y sacar ciertas partes al intérprete de comandos (command.com en DOS o bash en UNIX) ¿no?.
Estoy con greeneyed, está claro (como todo el mundo sabe) que es lo mismo trabajar con un maestro de 100 registros (u objetos) que con la información guardada en 300 millones de registros. Es por esta razón que la solución a adoptar para ambos casos puede ser la misma.
Era coña. Lo de BD's de objetos está muy bien para unas cosas, pero para las que requieran análisis de grandes volúmenes de datos, pues lo veo complicado. Empezando principalmente porque las propias BD's relacionales hacen trampas para optimizar rendimientos.
Jorge.M
@greeneyed: Lo mejor de lo mejor, que directamente de mi lenguaje de alto nivel yo diga "guarda" y automaticamente se decida todo por mi y se tengan en cuenta todos casos posibles, optimizaciones...
Yo quiero no tener que decir guarda. Si puede hacer todo eso, fijo que puede saber cuándo tiene que guardar.
Yo creo que aún tiene sentido dejar de utilizar DB relacionales por dos motivos:
@Anonimo(name="unknow")
Yo quiero no tener que decir guarda. Si puede hacer todo eso, fijo que puede saber cuándo tiene que guardar.
Pues no tienes que decir guarda en todo momento, mientras estes dentro del ambito de trasaccion y session con la base de datos lo que pase en ese ambito se guardara solo a la base de datos sin decirle guardar. Pero existe el guardar porque necesitas en muchos casos solamente guardar en el ultimo momento (menos idas a la BD)
Es verdad, anonimo, pudiendo hacer lo otro... solo una poco de mas de IA y ya hasta los objetos que quiero y no quiero guardar y cuando. Joer, necesitamos algo así pero ya!!
La verdad es que al leer todos estos comentarios uno no sabe si reír o llorar. Reír: por lo atrevidos que llegan a ser algunos proponiendo o prediciendo la desaparición de las bases de datos relacionales. Llorar: por lo atrevidos que llegan a ser algunos proponiendo o prediciendo la desaparición de las bases de datos relacionales. ¿De verdad creéis que algún organismo que tenga todos sus datos corporativos guardados en, por ejemplo, una base de datos relacional de Oracle puede plantearse el cambiar a una base de datos orientada a objetos? ¡Por favor, a ver si os enteráis de una vez de que lo importante es LA INFORMACIÓN guardada en las bases de datos relacionales, NO las efímeras aplicaciones web que se crean en determinados momentos para consultar o gestionar los datos. Las grandes corporaciones guardan sus datos en mainframes de IBM o en bases de datos relacionales desde hace decenas de años, y no van a cambiar ahora por el hecho de que ahora esté de moda la orientación a objetos. Tenedlo claro: en el mundo empresarial la imformación es "relacional", no "orientada a objetos".
...las efímeras aplicaciones web que se crean en determinados momentos para consultar o gestionar los datos
Ahi les ha dado, a ver que se creen esos hippies que hacen mariconaditas con el front page, cuando lo unico importante son las bases de datos, mi tesoooooooro. Menos mal que todo el mundo es una mega-corporacion y por lo tanto, café para todos.
¡Viva el radicalismo!
Tendré que cambiarme a las gominolas.
En mi entorno actual (megacorporativo), las BD relacionales son para aplicaciones accesorias, lo importante de verdad está en ficheros indexados en el host 390. (cierto que ahora lo "recubren" con una capa SQL DB2, pero el core sigue atacándoles con el cobol de toda la vida...)....
Así que estoy con greeneyed, no todo es igual, y la pregunta es "almacenar un modelo de objetos en una BD relacional"..., no " cambiar una bd relacional que tenemos que explotar con java a una bd oo"...
Y realmente, al principio de las BBDD relacionales, se decía (y sucedía) lo mismo que ahora con la orientadas a objeto, así que, tiempo al hardware...
Saludos
El dilema del almacenamiento de la información que da vida a los sistemas es de larga data.
Voy a tratar de ser sintético pero va a ser difícil.:
Por una parte: Aunque la teoría, y el sentido común indican que los desarrolladores y las empresas eligen siempre la mejor opción para sus sistemas , la cruda realidad no es esa. El mercado de las bases de datos es un mercado oportunista, y lo fue desde sus comienzos. Un breve ejemplo:
Cuando Larry Ellison (uno de los fundadores de ORACLE) vio la oportunidad de comercializar la tecnología de las bases de datos relacionales(RDBMS) a principios de los años 80 prácticamente no tuvo que desplazar a ninguna tecnología existente, además fue a partir de los años 80 que se realizaron gran parte(no todos) de los grandes sistemas hoy vigentes.
1ero) Supongamos que dentro de la misma tecnología(RDBMS) aparecen opciones mas económicas , para el caso que estamos analizando podríamos hablar de MySQL.
Aun con todas las ventajas económicas que representa saltarse a MySQL, le ha tomado varios años a MySQL llegar a donde hoy día se encuentra, y estamos hablando de la misma tecnología es decir Bases de datos relacionales.
2do)Para que una nueva tecnología se imponga y desplace a otra exitosa y ya existente como son las bases de datos relacionales, se requiere de algo mas que argumentos teóricos.
Si, el rival de las bases de datos relacionales(RDBMS) fueran las orientadas a objetos(OODBMS) yo diría que la lucha seria totalmente desigual.
Las OODBMS hoy por hoy no pueden plantearse como rivales de las RDBMS simplemente debido a que la base instalada de sistemas apoyados en RDBMS es superior al 90 %.
En este marco, aun con todas sus virtudes, las OODBMS solo pueden internar ocupar lugares, en los cuales su superioridad técnica es realmente notoria; Por ejemplo: sistemas GIS, Biotecnología , etc.
Para resumir:
Ventajas de las OODBMS sobre las RDBMS:
-No hay necesidad de mapeos , el modelo OO simplemente se almacena en la BD
-Velocidad: principalmente en la navegación de las relaciones entre objetos (esta es su principal fortaleza).
-Claridad: quien haya observado una RDBMS mapeada (por ejemplo: con TopLink, Kodo, Hibernate ) se habrá encontrado con tablas que a simple vista no describen nada claro, es decir muchos campos IDx1 - IDx2 , etc. Básicamente un embrollo.
(Existe una nueva ventaja para las OODBMS en cuanto a la velocidad debido a la aparición de los discos de estado sólido (SSD), esto es así debido a la forma interna en la cual trabajan las OODBMS , las cuales hacen uso intensivo del acceso aleatorio a discos.
En cambio las RDBMS están basadas casi íntegramente en estructuras B+Tree que se aprovechan mucho mejor el acceso secuencial de los discos mecánicos .
Los nuevos discos de estado sólido (SSD) tienen un acceso aleatorio mucho mas rápido que los mecánicos (entre 40 y 100 veces mas rápido), sin embargo su acceso secuencial es como máximo 2 veces el de los mecánicos.
Dicho esto es clara la ventaja de las OODBMS para aprovechar las bondades de los (SSD).
Ventajas de las RDBMS sobre las OODBMS:
-Base instalada.
- Diversidad de productos y soporte.
-Cantidad de desarrolladores que conocen la tecnología.
-Velocidad para ejecutar cierto tipo de consultas complejas(aun un punto flaco de las OODBMS).
-Precio. Aunque existen OODBMS opensource y free , las OODBMS para uso empresarial son caras y escasas.
Finalmente la principal ventaja de las RDBMS sobre las OODBMS:
Aunque parezca extraño a esta altura del siglo XXI , son pocos los programadores que comprenden y aplican el diseño orientado a objetos.
Aprender a diseñar un sistema orientado a objetos toma años de practica y experiencia, máxime para aquellos que se acostumbraron a ver sus sistemas en forma de tablas.
Porque seguimos pensando que la responsabilidad de un programador es la base de datos?
Nos quejamos tanto en esta profesión del intrusiomo, que dentro de esta mismo profesión no vemos el intrusismo entre roles. O es que un programador es un arquitecto de Sowftware, o un analista de sistemas o un diseñador de webs.
Vale que hacemos funciones de todo ello, a cierto nivel y sudamos cuando diseñamos y sudamos cuando montamos unas SQL.
Digo todo esto, no porque sea DBA, pero he visto las maravillas que hacen con el DB2, el Oracle o el MySQL. MetaVistas, Recuperaciones, balanceos de datos, gestion de los tablaspaces. Creo que los sistemas gestores de las bases de datos relacionales de hoy en día estan muy por encima de los Orientados a Objetos. ¿porqué cargarselos?
Si estas desarrollando una solucion y quieres utilizar una base de datos orientada a objetos adelante, tienes soluciones muy buenas como las comentadas anteriormente.
Creo que cada cosa tiene su espacio, y unas de las mejores soluciones y revolucionarias de nuestro mundo fueron los ORM, casi tanto como un lenguaje de programacion nuevo. Y creo que estamos metiendo los pies en la charca del vecino :)
Vean el poder de .net :P
Una pregunta: usando OODBMS, ¿qué pasa si se modifica la clase cuyos objetos están en la base de datos a la hora de intentar cargarlos?, ¿o si queremos añadir en base de datos una nueva columna/atributo, o modificar el tipo? ¿se comporta bien? En un sistema relacional existe una clara separación entre los datos del negocio - que se pueden acceder y ser explotados desde distintos sistemas - y los objetos de una aplicación que se cargan con datos de las tablas.
Respuesta para el ultimo anónimo:
Las bases de datos orientadas a objetos son bastante diferentes a las relacionales:
"si queremos añadir en base de datos una nueva columna/atributo, o modificar el tipo"
Las OODMBS poseen herramientas para administrar la base de datos en cuanto a la "schemma evolution" , es decir al cambio del modelo.
Además en algunos casos permiten versionamiento, en estos casos no solo permite actualizar el modelo (los nombres de clases, campos , etc.. etc) sino que cada versión guarda una compatibilidad con un modelo, el cual puede ser diferente.
Si, por ejemplo, Db4o permite refactorizar las clases sin ningun problema (cambio de nombre de campos, añadir, borrar,...) y los datos del modelo anterior se mantienen en la BBDD. Y esa es otra de las grandes ventajas de las BDOO, que cambiar la estructura de una Clase es sencillo, manteniendo una estructura clara de los ficheros.
Yo actualmente estoy desarrollando una aplicación (framework) para escritorio que usa Db4o, y puedo decir que para aplicaciones de escritorio es la mejor opción, haciendo que el desarrollo sea sencillo y robusto.
Realmente los dos modelos, en el fondo, son muy similares:
Tabla <=> Clase
Tupla <=> Objeto
Columna <=> Atributo (campo)
Procedimiento Almacenado <=> Método
*Evidentemente la relación no estan directa (algunas más, otras menos)
· En cuanto a las consultas, con Db4o son sencillas de hacer a nivel lenguaje, no obstante siempre se necesitará un lenguaje para la consulta, de hecho yo estoy utilizando uno propio y con soporte de SQL básico.
· A medida que he estado avanzando en el proyecto me he dado cuenta que básicamente, en el fondo, los dos modelos son iguales. La formar de guardar los datos físicos es casi igual, evidentemente en lo único que se diferencian son en las capas de arriba y en la gestión de los mismos.
Muy básicamente se podrían definir las siguientes capas (o pasos) para los diferentes modelos:
Un RDBMS:
1. Capa Física (datos)
2. RDBMS (gestor)
3. SQL => Resultados (planos)
RDBMS con ORM:
1. Capa Fisica
2. RDBMS
3. SQL => Resultado
4. Mapeado Objetos
Un OODBMS:
1. Capa física (datos)
2. OODBMS (gestor)
3. Resultado => Objetos
Creo que el enfoque que se le está dando a los OODBMS, NO es el correcto, porque el problema que le veo es la compatibilidad hacia otras plataformas, es decir, no se puede cerrar los datos a una o pocas plataformas (Java ó .Net). La única solución que le veo es ir a por un estandar para el intercambio de datos orientado a objetos. Y no sólo se necesita un estandar para este intercambio de datos, también se necesita uno para la construcción del modelo de datos, en el que se diferencie bien la separación de lo que son datos de la lógica. Eso de mezclar cosas, a veces salen cosas raras (Ej: que se almacenen datos que no deberían, etc...).
Pero claro, dicho esto, parece que esto es rizar el rizo, ya que tenemos un modelo más que comprobado, con muchas aplicaciones sobre dicho modelo, mucha documentación y comunidad desarrolladora. Por ello creo que, hasta que el modelo de BDOO no este totalmente definido y estandarizado, no será alternativa al modelo Relacional. Yo apuesto por una mejora del modelo actual, sin cambiarlo, añadiendole funcionalidades de orientación a objetos.
Hoy por hoy, para lo que si que son muy útiles las OODBMS es para entornos locales pequeños (escritorio, moviles, pequeños servidores muy especificos, etc...). Salirse de él es añadirle capas al modelo para darle compatibilidad a otras plataformas y eso sin tener un estandar definido no es recomendable.
Un saludo.
En las aplicaciones "de empresa", no se habla de objetos, sino de procesos sobre datos. Por eso, la orientación a objetos, que está muy bien para interfaces gráficos y para algunas librerías, no tiene cabida en la empresa. En las grandes empresas siguen usando mainframes de IBM o bases de datos Oracle (y, en algunas empresas, están empezando a meter mysql para los datos menos importantes), y se sigue realizando programación estructurada tradicional (muy adecuada para hacer procesos sobre datos), incluso aunque se usen lenguajes orientados a objetos.
"...La única solución que le veo es ir a por un estandar para el intercambio de datos orientado a objetos. Y no sólo se necesita un estandar para este intercambio de datos, también se necesita uno para la construcción del modelo de datos, en el que se diferencie bien la separación de lo que son datos de la lógica..."
Estás hablando del ADO.Net Entity Framework?
Al anonimo anterior:
Toda empresa almacena su informacion organizandola en un modelo.
Si se usan bases de datos relacionales el modelo es "Entidad-Relacion".
Si se usan bases de datos orientadas a objetos el modelo es "Orientado a Objetos".
Existen muchas empresas cuyos modelos estan Orientados a objetos, muchas empresas de comunicacion , entidades Bancarias, etc. utilizan Orientacion a objetos e incluso Bases de datos orientadas a objetos.
Por si tienes alguna duda te sugiero que veas estos links de empresas de diferentes ramos utilizando Bases de datos Orientadas a Objetos:
Algunas de las empresas Utilizando Objectivity:
http://www.objectivity.com/pages/downloads/successstories.asp
Algunas de las empresas Utilizando ObjectStore:
http://www.progress.com/objectstore/customers/index.ssp
Algunas de las empresas Utilizando Versant:
http://www.versant.com/en_US/aboutus/customers
Algunas de las empresas Utilizando DB4O:
http://www.db4o.com/about/customers/
Algunas de las empresas Utilizando GemStone:
http://www.gemstone.com/partners/customers.php
La respuesta anterior es para el anonimo de las
30/05/2008 11:44
¿Y Caché? http://www.intersystems.com/cache/
Hola a todos ante todo mi nombre es Juan Icaza y siempre leo este foro porque me parece muy instructivo y considero que me mantiene al dia en el tema que me interesa 'Java' .
La pregunta que tengo es la siguiente:
Que opinion le merece a ustedes la forma como google maneja sus sistemas, me refiero a como almacena los datos con bigtable y como ellos no utilizan base de datos alguna , bueno si la utilizan (bigtable) de una forma que me parece totalmente distinta a lo acostumbrado; aclaro que no soy un experto en este tema pero me gustaria saber que opinan el enfoque google y mas ahora que han abierto su plataforma para poder usar todo ese poder en nuestras aplicaciones (Google App Engine)
aqui un link que habla sobre el api de google
http://code.google.com/appengine/docs/datastore/
y en youtube mas informacion
http://www.youtube.com/results?search_query=Google+App+Engine&search_type=
"¿Y Caché? http://www.intersystems.com/cache/"
Bueno, IntersystemCaché no es una OODB , es decir un abase de datos orientada a objetos.
IntersystemCaché es una base de datos relacional (permite consultarala via SQL ), yo la he usado durante años , es muy buena y lo que si tiene es: Una cache sobre la BaseRelacional que actua como una OODB.
En definitiva una Base de datos relacional con un ORM embebido
Al último anónimo, gracias por la explicación.
Yo no creo que el modelo relacional y el orientado a objetos sean tan parecidos. De hecho, porque no lo son es por lo que surge la falta de correspondencia entre ambos. Al fin y al cabo, el modelo relacional tiene como concepto matemático básico el conjunto y el modelo orientado a objetos tiene el de álgebra. Y no son lo mismo, ni mucho menos. Claro que el modelo relacional puede aproximarse al orientado a objetos de algún modo mediante los procedimientos almacenados, pero estos últimos son un añadido posterior y no forman realmente parte del modelo relacional. De hecho, los procedimientos almacenados son más parecidos a procedimientos de un lenguaje estructurado tipo Pascal, que pueden acceder a datos globales, que a un método que pertenece a una clase y que sólo puede acceder a atributos de ésta.
Sobre la estandarización de las BBOO, lo que me parece fundamental -teniendo en cuenta que SQL es un estándar hasta cierto punto porque cada SGBD tiene su dialecto propio- ¿no existe un estándar ODMG para los lenguajes de programación orientados a objetos persistentes?
Saludos.
Que opinion le merece a ustedes la forma como google maneja sus sistemas...
No todo el mundo es Google ni tiene las mismas necesidades/caracterísiticas. De igual forma que los coches de formula 1 son adecuados y estupendos para lo que hacen, pero para el 99% de la poblacion no nos servirian de nada. Y tambien de la misma forma, se aprenden cosas que sirven a todos, pero la solucion no es trasladable "tal cual" en la mayoria de casos.
"Sobre la estandarización de las BBOO"
Aunque la ODMG tiene un estandard ahora en la version 3, la verdad, es que no es muy usado en el ambito java.
Para el lenguaje java lo mas usado es JDO.
ObjectStore y Versant son las dos principales OODB del mercado e implementa la especificacion JDO, y ademas agregan un poco de funciones propietarias.
Objectivity dice implementar JDO pero eso no es cierto, Objectivity implementa una interface propietaria.Lo mismo sucede con DB4O(aunque puede ser accedida desde JPOX usando JDO) y Gemstone.
Escribe tu comentario