Si, si, es una predicción medio loca y hasta pareciera absurda dado el estado actual de tecnologías, pero hay mucho indicios que me llevan a pensar lo que puse en el título.
En realidad, son todos indicios tecnológicos y no de negocios, pero como nuestra profesión se basa en la tecnología creo que en algún momento se hará fuerte una tecnología que desplazará a las base de datos relacionales de la misma manera que ellas desplazaron a los archivos jerárquicos (como vsam, etc).
Lo que me llevó a pensar esto nuevamente es un proyecto en el cual estoy haciendo coaching en el cual estamos usando Java como lenguaje de programación y Hibernate para conectarnos a una base de datos relacional. Hubo dos "colaboraciones" que me hicieron recordar lo antiguo de esta tecnología:
1) Cada vez que se quiere persistir un objeto, hay que hacer: session.save(anObject)
2) Cada vez que se quiere borrar un objeto, hay que hacer: session.delete(anObject)
¿Qué tiene de malo tener que hacer esto? Simplemente que en otras tecnologías no es necesario hacerlo! por lo tanto son más simples desde el punto de vista de utilización lo que implica que son menos propensas a error.
Para el caso 1), en una tecnología como la que usa GemStone, no es necesario decirle a un objeto que quiero que se persista, simplemente si ese objeto es referenciado desde un objeto persistido, este se persiste. Simple, natural, lógico.
El caso 2) es quizá el más fuerte puesto que me hizo acordar al manejo de memoria manual, ¿recuerdan c++, tener que hacer "delete anObject" para desalocarlo y todos los problemas que ello conllevaba? Acá estamos en el mismo caso, utilizar base de datos relacionales es como utilizar un manejo de memoria manual algo que por suerte ya está abandonado (salvo para casos muy particulares). ¿Por qué tenemos que borrar un objeto explícitamente cuando el mismo puede desaparecer automáticamente, como cuando se realiza un garbage collect?. Por suerte ya hay tecnologías que hacen esto (de vuelta GemStone) y "borran" objetos cuando los mismos no están más referenciados. Simple, natural, lógico.
Creo que estos dos casos son indicios que muestran que trabajar con base de datos relacionales en algún momento tiene que cambiar. En algún momento nos tenemos que dar cuenta que trabajar con ellas es trabajar en un paradigma "viejo", similar al procedural donde se separan "datos" de "código", en vez de utilizar un paradigma que ya está probado ser más robusto y escalable para desarrollo de aplicaciones como el de objetos.
Claro está que la base de datos relacionales tienen sus ventajas. Por ahí la más fuerte desde el punto de vista tecnológico es el SQL, pero al mismo tiempo para mi es su cruz, es lo que no va a permitir que la tecnología evolucione, cambie paradigmáticamente. Y por supuesto no hay que dejar de ver la fuerza comercial que ellas tienen, pero como dije antes, en algún momento la comunidad estará preparada para algo nuevo, distinto, cuando se cansen de tener que hacer save y delete y se den cuenta que si en memoria no hay que hacer eso, ¿por qué hay que hacerlo con el disco?, en definitiva el disco es "memoria" y debería estar abstraído (salvo cuando hay que hacer aplicaciones que deben diferenciarlos :-) ).
Claro está que a los dos problemas que mencioné hay que agregar varios más, como el problemático mapeo, manejo de identidad, manejo de caching y unicidad, etc., problemas que en otras tecnologías no existen...
Para concluir, ¿cuándo pasará esto? No creo que rápidamente... de la misma manera que a las base de datos relacionales les costó desplazar a los archivos planos y jerárquicos, no será inmediato reemplazar a estas. Por ahí en 10 años se empiece a divisar y entender que hay una alternativa a ellas, no creo que antes, a menos que aparezca un player nuevo en la comunidad, un player que sea respetado y tenga fuerza y logre imponer el quiebre paradigmático... por ahí ese player puede ser VMWare si se da cuenta del productozo que compró (GemStone), pero habrá que ver si sus "gurús" logran salirse del paradigma actual y ver más allá... el tiempo dirá.
Suscribirse a:
Comentarios de la entrada (Atom)
8 comentarios:
Estoy de acuerdo.
Algo que leí una vez en un blog una vez es que planteaba como desventaja el hecho que vos nombras, que en una base de objetos (como gemstone) los "datos" y el "código" están acoplados. que en una base de datos se puede acceder desde diferentes lenguajes por no estar ese acoplamiento, etc.
En algún punto es cierto, en relacional hay un acoplamiento con el modelo relacional obviamente, pero no está definido el comportamiento del programa que usa esos "datos".
Obviamente prefiero pagar el precio de esa desventaja y tener una base de objetos, pero que opinas de esa desventaja?
Pero si fuese verdad que es una desventaja ese acoplamiento, ¿por qué usamos objetos en vez de funciones y datos?. Yo no veo como desventaja que estén juntos "datos" y "código" (que asqueroso hablar de eso!), quizá la desventaja es que hasta ahora la técnología que hay sólo permite que sea un solo lenguaje el que se utilice... pero imaginemos una base de objetos donde el lenguaje no importe, donde pueda ser java, .net, etc. En dicho caso sería lo mismo que ahora con una base relacional, o por ahí mejor.
Pensando en esto, otra de las ideas que tengo es que el próximo lenguaje de programación que romperá los esquemas es para mi uno donde el tema de la persistencia y la transaccionabilidad estén directamente integrados y donde todo sean objetos (y por supuesto, dinámicamente tipado :-))... veremos si se da...
Hola Hernan,
Concuerdo complemente con un viejo post tuyo en el que comentabas que el mundo del mapeo relacional no es un problema de forma sino de fondo. Pero como en todo, lo comcercial marca la tendencia, y también el miedo del cliente a otras posibles formas de persistencia "desconocidas" y que solo unos pocos usan.
Si me diesen la libertad de encarar un proyecto en Java sin duda evitaria completamente el mundo ACID, hace ya un tiempo relativamente largo vengo evaluando otras formas de persistencia y cada dia estoy menos convencido de que Hibernate o cualquier otra herramienta ORM + RDBMS es la opción a elegir.
Si un software es un modelo computable de un dominio de problema de la realidad, entonces porque acoplar esa realidad a un mundo completamente consistente, cuando el mundo no lo es? Por qué en el mundo Java todos van por el camino de Hibernate + RDBMS? Yo creo que es por un gran desconocimiento, acompañado de costumbre y falta de vocación en muchos casos aunque también puede ser como condición impuesta por el cliente. Cada vez hay más gente que sabe Java como lenguaje, pero que sepan Java no implica que sean programadores por vocación, y si no son programadores por vocación no miran más allá de lo que hacen todos los días en sus respectivos trabajos, que en la mayoria de los casos es una aplicación CRUD.
Te dejo un articulo muy interesante sobre una observación del mundo real en donde se aprecia como el mundo es eventualmente consistente y contradice la naturaleza transaccional de las bases de datos relaciones:
http://www.eaipatterns.com/ramblings/18_starbucks.html
Imaginate ir a un restaurante y ordenamos un plato... si nos manejamos en un mundo ACID y nos damos cuenta de que el plato que pedimos no nos convence y lo queremos cambiar... imposible! Nos Vamos a tener que esperar a que nos traigan el plato que nos disgusta para recién luego decirle al mozo sobre el cambio.
La tendencia NoSql está de a poquito tomando fuerza. Yo particularmente apoyo la idea de tener dos modelos en un software, uno que represente la parte "transaccional" y se maneje mediante NoSql (OODB, EventSourcing, etc) y otro que represente mediante tablas relacionales desnormalizadas las vistas del software. Cual es el costo? Mantener los dos modelos sincronizados. Pero las ganacias son infinitas, desde escalar cada modelo por separado hasta poder usar justamente metodos de persistencia independientes segun la naturaleza de cada modelo... que mejor que NoSql para procesar comandos y que mejor que SQL para la parte de reporting/queries, y acciones compensadoras (que sí imitan la realidad) para deshacer ("rollbackear") los cambios.
El patrón UnitOfWork que todos usan y que esta implementado en Hibernate y muchos otros ORMs es en realidad un antipattern... nos garantiza la consistencia cuando persistimos más de un objeto cuando justamente los objetos son los que deben operar de tal modo que al haber colaborado finalmente las invariantes no sean violadas. Por ello, si optamos por UOW entonces es porque habra que repensar los límites de consistencia que definimos para aquellos objetos mutables de nuestro modelo.
Saludos!!
Sebastián.
Que tal Sebastian, muy interesante tu comentario... me parece buenísimo pensar de manera distinta y romper el status quo... veremos que pasa.
Esto va a pasar recien cuando las bases de datos guarden informacion semantica y puedan descomponer las complicadas relaciones entre objetos en tablas.
Mientras tanto los problemas de performance seguiran siendo la cruz del paradigma de objetos (como siempre)
No creo que le problema sea la performance ahora... cuando aparecieron la bases relacionales decían lo mismo aquellos que usaban archivos vsam o jerárquicos, que las bases de datos relacionales eran más lentas y tenían razón, pero dejó de ser un problema como siempre pasa con la performance debido al avance tecnológico.
Ahora, usar base de objetos con discos de estado sólido es casi lo mismo que tener memoria física, rapidísimo, una vez que se impongan ese tipo de discos y la gente empiece a ver que desarrollar con bases de objetos es muchísimo más productivo que con bases relacionales, el cambio se realizará
Llego muy tarde a la discusion. Pero bue..
Las bases de datos orientadas a objetos estan hace año dando vuelta y su evolucion en el mercado ha muy modesta.
El problema esta en enforcarse exclusivamente desde el punto de vista de desarrollo.
Hay todo un inmenso universo que usa las clasicas bases de datos relaciones y no sabe nada de Java ni objetos y ni necesita saberlo.
Como haga una solucion BI con gemstore?
La flexibilidad que tienen las bases de datos relacionales es iniguable en el mercado.
Que tal Eduardo, por supuesto que el desarrollo no es el único driver, pero a largo plazo la técnología y el costo de desarrollo es lo que termina haciendo que algunas tecnologías mueran y otras emergan.
La integración de cualquier base de objetos se puede solucionar tan bien como la de cualquier Base relacional, la misma pregunta que vos haces la hicieron (salvando las diferencias) años atrás la gente que trabajaba con VSAM (por ejemplo) cuando aparecieron las bases relacionales... es solo cuestión de tiempo.
Publicar un comentario