Rel Project: Una base de datos relacional (en Java) como deberian de ser? Parte I - Proyeccion
El proyecto Rel es una implementación del lenguaje Tutorial D de Date y Darwen en Java.
Rel es una verdadera RDBMS (no como Oracle, SQLServer o DB2 que son solo pseudo relacionales) con un lenguaje de consultas avanzado.
Rel es gratuito y opensource
Rel implementa un conjunto extendido del lenguaje propuesto por C. J. Date y Hugh Darwen, llamado Tutorial D. Es posible que ya lo hayas visto si alguna ves leíste el libro "Introducción a los Sistemas de Base de Datos" de Date.
El objetivo principal de Rel es como una herramienta de enseñanza, para que podamos explorar los conceptos de las bases de datos relacionales, pero lo que me impresiono sobre el, es que tras conocerlo se volvió imposible para mi el considerar a SQL como una lenguaje bien diseñado. Tutorial D te hace ver que SQL es una reliquia de de los 70 de la que ya deberíamos habernos deshecho hace mucho tiempo... y sin embargo, seguimos creando lenguajes para consultas lo mas parecidos a SQL que podemos, con el objetivo de facilitarle el aprendizaje a las personas que ya saben SQL, sin darnos cuenta que el aprender SQL en si mismo es una fuerte limitación a la productividad.
Empecemos con la operación relacional proyeccion: Veamos una comparación:
En SQL, puedo escribir:
Con lo que obtendré una consulta con las columnas a, b, c de la tabla r.
En Tutorial D dicha consulta se escribiría (en SQL es necesario escribir DISTINCT para garantizar que la salida no tenga redundancia, en Tutorial D, la redundancia esta prohibida por default por los principios Relacionales):
Que es mucho mas corto, hasta el momento, parece que esta es la única ventaja, pero ahora supongamos que la tabla "r" tiene los campos: a,b,c,d,e,f,g,h,i, y que solo queremos ver los campos d,e,f,g,h,i.
En SQL escribiria:
Mientras que en Tutorial D escribiria:
Es importante notar, que la instrucción en Tutorial D cuenta con comportamiento dinámico que la de SQL no tiene: si yo llegara a agregar una nueva columna "j" a la tabla "r", la consulta en Tutorial D me mostraría: d,e,f,g,h,i, j, mientras que la consulta en SQL me mostraría d,e,f,g,h,i. En otras palabras imposible replicar con una simple consulta el comportamiento del "ALL BUT" de Tutorial D en SQL.
Cuantas veces no hemos tenido que mostrar una consulta "menos 1 o 2 campos" y hemos tenido que escribir los nombres de todos por que tenemos que usar SQL o uno de sus primos (JPAQL, EJBQL, HQL, etc)?
Ahora veamos el renombrado de columnas. En SQL, si quiero renombrar 1 columna de la tabla "r" y mostrar las otras con sus nombre originales tengo que escribir :
Tengo que poner a todas las columnas en la lista, aun cuando no quiera hacer otra cosa con ella que indicar que quiero mostrarlas
En Tutorial D yo escribiría:
Y tendría el mismo resultado. Probablemente sea importante mencionar aquí que:
es equivalente en Tutorial D a poner solamente:
Lo mas cerca que se puede llegar a algo tan conciso en SQL es escribir SELECT * FROM r, pero creer que escribir:
es equivalente seria un error.
El resultado de seria X,b,c,d,e,f,g,h,i
El resultado de seria: X,a,b,c,d,e,f,g,h,i,
Notan al "a" que sobra cuando se usa SQL? Este es otro caso en que SQL nos complica innecesariamente la vida.
Estos son solo unos cuantos ejemplos (con consultas simples) de como las carencias en vision que se tuvieron al diseñar SQL alla en los 70s, resultan en esfuerzos innecesarios hoy en dia (e inclusive en la creación de nuevos lenguajes de consultas como HSQL, o JPAQL que replican estos mismos errores hasta el cansancio). Cuando las consultas se vuelven mas complejas, las suma de estas y otras deficiencias convierten a la creación de SQL en una excelente herramienta de tortura mental.
Digamos que por ejemplo, quisiéramos renombrar a la columna "a" en "X", quitar a la columna "b" y agregar una columna nueva g+h que se llame "z".
En SQL:
En Tutorial D:
No tenemos necesidad de mencionar a las columnas que no nos interesa afectar, y el código es claro y muestra directamente lo que hace (su intención es visible directamente) mientras que en SQL, es posible que nos costara darnos cuenta, después de algunos dias o semanas, si quitamos a la columna "b" de la consulta accidentalmente o a propósito, y si alguna de las otra columnas cambio de nombre (o se agrego alguna mas) tendremos que ajustar nuestra consulta para que siga funcionando
Desgraciadamente, la mayoría de la gente relaciona a SQL con "Relacional" y piensa que como SQL es un lenguaje que causa muchos dolores de cabeza a quien lo usa, entonces el enfoque Relacional para manipular la información es incorrecto. Pero la realidad es que en estos tiempos prácticamente ninguna de las bases de datos lideres en el mercado es verdaderamente relacional: son Pseudo-Relacionales, implementan de una forma muy limitada los principios Relacionales, y son esas limitaciones, y no el enfoque relacional lo que las convierte en un problema para el desempeño de los proyectos.
Esto resulta en poco interes de la comunidad opensource de Java en participar en proyectos como Rel... y un interes desmedido en crear frameworks como JPA que mediante ORM intentan cubrir las limitaciones del modelo pseudo-relacional de la mayoria de las bases de datos actuales. Los ORMs no son en si mismos una mala idea, pero si uno observa cuidadosamente sus lenguajes de consulta, es facil notar que en muchos sentidos replican el mismo enfoque incorrecto a la hora de escribir consultas que SQL se ha encargado de hacer tan popular. De hecho, Tutorial D cuenta con varias extensiones Orientadas a Objetos con lo que intenta disminuir la "impedancia" entre el enfoque relacional y el orientado a objetos, pero como la mayoría de la gente no conoce este enfoque, los mismos errores son repetidos en distintos ORMs, sin que parezca que haya escapatoria posible por que: "es es el modo como todos lo resuelven".
Si quieren aprender mas sobre Tutorial D, aqui hay un curso (en ingles) muy completo.
Y mas información general sobre proyecto (comerciales y opensource) que intentan implementar bases de datos verdaderamente relacionales disponible (también en ingles) en TheThirdManifesto.com
En la segunda parte hablare sobre las "relvar" y como la existencia de verdaderas variables relacionales hace mucho mas fácil la creación y el mantenimiento de consultas.
- luxspes's blog
- Inicie sesión o regístrese para enviar comentarios
Sintaxis
Mencionas que Rel es verdaderamente relacional mientras que las otras que conocemos son pseudo-relacionales, pero luego te enfocas a hablar solamente de la diferencia de sintaxis entre el lenguaje de Rel y SQL.
Así como lo veo, se podría hacer un frontend que interprete Rel y lo convierta a SQL y se obtentan los mismos resultados (al menos para todo lo que explicaste aquí).
Podrías explicar más acerca de por qué Rel es verdaderamente relacional y las otras no? Hay algo además de la sintaxis? esperaba leer algo acerca de normalización o integridad o cosas así, no solamente la sintaxis del lenguaje, que de todas formas si usáramos algo como Hibernate o herramientas similares, no vamos a tratar directamente con el lenguaje.
Rel tiene triggers, restricciones en columnas, restricciones de integridad referencial, etc? O no se necesitan (y por qué no se necesitan)?
Este proyecto de Rel, soporta ya tablas con varios millones de registros y ofrece buen tiempo de respuesta al consultar dichas tablas, así como al insertar a las mismas? qué tal la concurrencia? Cómo se comporta con varias conexiones realizando operaciones similares en las mismas tablas al mismo tiempo? Hay transaccionalidad? o no es necesaria (y por qué)?
Todas muy buenas preguntas...
Son todas muy buenas preguntas, por eso el titulo de este blog post dice al final "Parte I" (y al final menciono que vendra otro despues con explicacion sobre las relvar). Por supuesto que me hubiera gustado explicar todo en un solo blog post, pero creo que hubiera quedado demasiado largo, asi que decidi hacer "mi primera serie" ;-).
Tienes razon en que se puede hacer un frontend que interprete Rel y lo convierta a SQL y se obtentan los mismos resultados, la pregunta es precisamente: por que nadie lo ha hecho (bueno casi nadie).
Por otro lado, claro que esta primera parte suena muy facil de implementar, pero la parte de las relvars ya se complica... (lo curioso es que son muy simples y comodas, y cuando las conoces no puedes creer que SQL no tenga algo asi... pero implementarlas sospecho que no esta tan facil).
Rel si tiene triggers y stored procedures (aunque en Rel todos se llaman operators, si te pones a ver un trigger es básicamente lo mismo que un stored procedure, la diferencia es que que responde a un evento determinado, si pudiera "conectar" un stored procedure al evento "on insert" de una tabla, entonces tendrias un trigger).
Rel tiene restricciones de integridad referencial que hacen ver a las disponibles en las bases de datos pseudo relacionales como algo patetico (esa es una diferencia clave entre las pseudo y una relacional: el poder que esta disponible a la hora de definir reglas de integridad en un lenguage relacional). Puedes por ejemplo, definir reglas a nivel de toda la base datos (no puede haber un Cliente con una deuda de mas de 1000 pesos), o inclusive reglas referenciales con respecto a vistas (si debes o no hacerlo depende del problema que quieres resolver, el lenguage no te restringe, en una base de datos verdaderamente relacional, todo lo que se puede con una tabla, se puede con una vista). Hablare de esto mi siguiente blog post (junto con las relvar).
Y finalmente, no, este proyecto Rel no soporta ya tablas con varios millones de registros y ofrece buen tiempo de respuesta al consultar dichas tablas. Si hay transaccionalidad, si hay soporte de concurrencia (al menos de acuerdo con el spec de Darwen y Date), pero he probado a fondo a esa parte en Rel.
Rel es básicamente un proyecto académico, construido con la intención mas bien de enseñar y no ser utilizando (asi como esta ahorita) directamente en producción para un sistema del mundo real... Su intencion es hacerle ver a las personas que existe algo mejor que SQL y las bases de datos pseudo relacionales (y su famila de lenguages de consulta). Y claro que, como es opensource, podria evolucionar hasta ser un producto que compitiera con PostreSQL o MySQL
Mi intención con esta serie de blog posts es precisamente despertar el interes en este enfoque, con la esperanza de que lo que hacer Rel pueda propagarse y con el tiempo vaya apareciendo una nueva generacion de herramientas de manipulacion de datos que nos hagan mas facil la vida (en ves de que se propague el modo actual que nos la complica).... se que mi contribución tal ves sea solo como una gotita en medio del mar... pero por algo hay que empezar ;-)
Hibenate: No vamos a tratar directamente con el lenguaje?
Y con respecto a Hibernate... me alegraría de equivocarme... pero creo que creo que al menos en estos primeros ejemplos sencillos de proyeccion... JPAQL/HQL no tiene nada que ayude (nada como el RENAME, el ADD, el REMOVE o el ALL BUT).
Claro que podría tenerlo... pero no lo tiene... claro que el HQL Hibernate hace muchas otras cosas que son muy útiles, cómodas y ahorran trabajo, pero su lenguaje esta, en mi opinión, demasiado influenciado por SQL.
Estan tambien Criteria Queries... pero hasta donde se, tampoco son capaces de hacer lo que hace Rel (de hecho, hasta resultan mas incomodas que HQL, a menos que tu query sea dinamico, y aun ahi, el codigo resultante no es precisamente facil de leer)
Parte 2
Esperamos la parte 2 entonces. Y no te preocupes, es una buena contribución, lo primero que se necesita para cambiar de paradigma es hacerle ver a la gente que la situación actual está mal, y luego de ahí puede salir alguien que decida implementar esto de Rel ya de forma más robusta para sistemas reales.
Muy interesante
No conocía el proyecto, pero para ser un proyecto académico está MUY bien diseñado, y eso lo digo solamente por el preview que nos has dado que solo cubre las diferencias en cuanto al lenguaje.
Francamente me quedé picado en el tema, ya quiero ver yo también la diferencia sustancial que tiene Rel en cuanto a ser realmente "relacional".
Que bueno que escribas sobre temas como este, pones al alcance de todos nosotros difundir también este tipo de proyectos.
Saludos!
Javier Ramírez Jr.
Muy interesante pero aún
Muy interesante pero aún seguimos en espera de las demás partes!!!
Me parece interesante tu
Me parece interesante tu artículo, pero creo que quizá esté fuera del paradigma de bases de datos actual.
En mi concepto, uno de los problemas más importantes del desarrollo de software actual es el salvar vacío que existe entre las bases de datos relacionales y la programación orientada a objeto. Por ello se han creado la gran cantidad de frameworks ORM que hoy en día conocemos. Así que, ¿No sería mejor investigar sobre bases de datos orientadas a objetos que eviten la necesidad de un ORM? Ya existen algunas muy interesantes en el mercado:
Existen otras que en el momento ya no recuerdo pero que pertenecen al movimiento NoSQL que puedes apreciar, junto con una lista completa de los proyectos en
El paradigma actual es insuficiente
Precisamente por eso escribo esta serie, por que el mercado parece querer abandonar las bases de datos relacionales (aunque no usado una jamas) e irse las orientadas a objetos (aunque históricamente han resultado un fracaso aun mayor que las que incorrectamente se auto-nombran relacionales)
Eso mismo intenta Rel, pero con un enfoque muy diferente al del tipico ORM que intenta hacernos creer que una relacion es lo mismo que una clase. En Rel tambien puedes crear clases/tipos (domains), pero todavia no he llegado ahi en estos tutoriales, y eso domains se usan para describir los valores que son validos en campos.
Checate la comparativa con neo4j y rel en la discusion al de este blog post. En mi opinion Rel supera facilmente a Neo4J en cuanto a facilidad de uso, poder de expresion, legibilidad del codigo, etc, etc. la unica razon por la que pierde es por que todavia no es una version final ¿No seria mejor abandonar el equivocado esfuerzo de crear bases de datos orientadas a objetos y ayudar a llevar a Rel o a Dataphor a buen termino, para poder tener, por primera vez en la historia, una base de datos relacional?.
Todas las conozco ya, todas ayudan a resolver ciertos problemas, pero todas, tambien, me parece que son para resolver problemas distintos a los que resolveria una base de datos relacional... son buenas para informacion poco estructurada, del tipo con el que trabarian proyectos como Google, en los que no importa que los resultados de las busquedas sean inconsistentes entre peticiones (si tu pides a Google que haga 2 busquedas, no te importa que haya consistencia, pero si tu buscas 2 veces en el sistema de nomina de una gran empresa, y la primera vez te devuelve que pago 2 millones para la primera quincena de 2010, y la segunda vez te dice que pago 3 millones para la primera quincena de 2010... estas un un gran, gran problema. Igualmente, esas bases de datos no se preocupan por la integridad de los datos, cuestiones como que 2 personas tengan asociada la misma cuenta bancaria, o que tengas un mensaje que no tenga autor, son irrelevantes para problemas como los que ellas resuelven, si la informacion no tiene sentido o es inconsistente no les importa, por que se usan mas para buscar en informacion sea cual sea su estado, que para garantizar que describan hechos siguiendo un modelo bien definido.
Esto es lo que yo creo acabara ocurriendo con la tendencia NoSql. Por otro lado, las bases de datos verdaderamente relacionales tiene un potencia inexplorado que podrian llevarnos a resolver de modo mas facil muchos problemas con los que sufrimos actualmente, solo por que desafortunadamente la gente hoy en dia cree que SQL es a lo mas que se puede llegar con el enfoque relacional. Ojala Rel o Dataphor logren demostrar lo equivocada que esta esa idea.
Hablando de reliquias que hay
Hablando de reliquias que hay de java?