Las bases de datos relacionales son tan populares que generalmente cuando empezamos a adentrarnos en el mundo de la tecnología y principalmente en la programación del lado del servidor o backend, da la sensación (al menos me paso a mi) de que son los únicos tipos de bases de datos que existen, después nos enteramos de las bases de datos de documentos como el famoso MongoDB y si somos más curiosos nos encontramos con DB-ENGINES.COM.
Según el sitio db-engines.com existen 334 bases de datos y los clasifica en 14 tipos o categorías de bases de datos.
Podemos notar que las bases de datos relacionales ganan por “goleada” a los otros tipos de bases de datos y desde que empezó a comercializarse en la década de 1980, el “mundo” como que se “enamoró” de las bases de datos relacionales.
Es innegable que las bases de datos relacionales facilitan muchísimo las consultas y evitan inconsistencias al insertar, eliminar y actualizar datos. Además de un montón de herramientas modernas que facilitan su uso.
Pero tablas, columnas, filas, índices, llaves, etc. ¿Es la única manera de pensar a la que podemos recurrir a la hora de empezar un proyecto que implique la persistencia de datos?
La respuesta es un rotundo NO, sabemos que existen bases de datos NoSQL y MongoDb es el más popular de todos ocupando el puesto numero 5 entre las 10 primeras bases de datos.
Pero quiero concentrarme en un tipo de base de datos que está revolucionando tímidamente la forma de pensar de una manera “espectacular” y va de la mano del “Event Sourcing”. El artículo de Barry O Sullivan lo explica muy bien de forma introductoria.
No quiero entrar en detalle sobre el “Event Sourcing” mi intención ahora es llamar la atención a las bases de datos del tipo EVENT STORE que según db-engine.com existen actualmente solo 3 bases de datos.
Para la mayoría de nosotros es casi natural hablar de tablas, procedimientos y demás detalles técnicos de la base de datos relacional que usamos, pero los expertos del dominio, ellos por lo general no manejan esa terminología y mucho menos piensan en términos de tablas relacionales. Esto es debido a que los expertos del dominio expresan los procesos de negocios como una serie de hechos secuenciales o eventos y no como tablas relacionadas.
Nosotros por inercia “agarramos” esas series de eventos y tratamos de “expresarlos” en tablas desde el mismo comienzo, es lo “natural” ¿o no?.
Al usar una base de datos de eventos, estamos modelando y pensando de la misma manera que hacen los expertos del dominio, es decir hablamos su “idioma”, esto hace que la comunicación sea fluida entre los que deben desarrollar y los que deben proveer el “know how”. Ya de entrada nos evitamos la “traducción” de eventos a tablas, una carga cognitiva menos. Además, hay técnicas muy interesantes para quitar el mayor provecho de las charlas con los expertos del domino como el EVENT STORMING
Cuando hablamos de tablas y los valores que contiene, estamos hablando de estados actuales, es decir la información actual que contiene, por ejemplo, la tabla proveedores en el campo de direcciones.
Cuando hablamos de eventos estamos contando una “historia”, no solamente sabemos que estado actual tiene. Por ejemplo, el campo dirección de la tabla proveedores, sabemos que para llegar a tener esa dirección, antes cambió 3 veces hasta llegar a la dirección actual que tiene, el “estado actual”.
Generalmente cuando usamos bases de datos relacionales, perdemos esas “historias” que cambian los estados de los datos en las tablas, es decir, si no guardáramos un historial de cambios de estado a propósito, perderemos esa información al sobrescribir (siguiendo con nuestro ejemplo) el campo dirección de la tabla proveedores, lo cual no ocurre en una base de datos de evento, porque “toda la historia” se guarda. Nada se pierde.
Esto es en sí mismo ya es una gran ventaja por las que vale la pena usar una base de datos de eventos siguiendo el patrón de diseño “Event Sourcing”.
Las bases de datos de eventos no son pioneras en usar secuencias de eventos, en realidad las bases de datos relacionales no les queda de otra que usar secuencia de eventos para manejar las transacciones y poder deshacer los cambios si algo sale mal.
Al fin y al cabo, nunca se preguntaron ¿Cómo maneja las transacciones y la consistencia una base de datos relacional por dentro? Es por medio de logs de transacciones, donde se guardan suficientes datos como para reproducir o deshacer un cambio, eureka eso es “Event Sourcing”.
Aparte de los logs de transacciones que usan las bases de datos relacionales para poder recuperar datos, reproducirlos, recuperarse ante desastres, etc. existen logs o registros que se refieren a “la grabación secuencial en un archivo o en una base de datos de todos los acontecimientos (eventos o acciones) que afectan a un proceso particular (aplicación, actividad de una red informática, etc.). De esta forma constituye una evidencia del comportamiento del sistema.”
Según Wikipedia se utilizan para:
¡Que pensarías si te dijera que con una base de datos de eventos tendrías todo eso y además podrías recrear las tablas en una base de datos relacional donde tienes datos de análisis o cualesquiera otras tablas, como lo hacen los gestores de bases de datos relacionales con su log de transacción!
Podemos “mirar” el pasado de la empresa y encontrar comportamientos de clientes, patrones de compras o de intenciones del cliente o del funcionario. Sabiendo, por ejemplo, quién y desde qué IP genero el evento; desde qué dispositivo, a qué hora minuto y segundo. Incluso desde qué ubicación geográfica si guardamos eso como metadato del evento y muchas cosas más porque en una base de datos de eventos, ninguna historia o evento de la empresa se pierde y eso está garantizado.
Es genial cuando un usuario te llama y dice “el sistema no me funciona” y miras los eventos que está generando “en tiempo real” y te das cuenta de que, por ejemplo, no ve los datos que está buscando porque coloco un filtro que no está teniendo en cuenta y por eso no le salen los datos que espera. O que no entra en el sistema porque no permitió al navegador geolocalizarse y por eso el sistema le rechaza y ¡se lo dice! pero el usuario no lee el mensaje, y eso sin mirar el monitor del usuario ¡Solo la base de datos de eventos!, es genial la verdad.
El patrón de diseño EVENT SOURCING esta dando que hablar “tímidamente” en todo el mundo, solo busquen “Event Sourcing and CQRS” o vean videos de “Greg Young”. Si no me equivoco sería como el padre del EVENT SOURCING o al menos el principal “precursor” y aunque no hay tanto material como cuando buscamos algo de bases de datos relacional, se pueden encontrar cosas interesantes.
En fin, en el trabajo estamos usando EVENTSTORE como base de datos principal (fuente de la verdad) y SQL SERVER para proyectar los eventos y así quitar reportes, analizar datos, etc. Y pasa a veces que nos divertimos viendo que están haciendo los usuarios y observando sus “comportamientos” en el sistema.
Si quieren que escriba más sobre esto o de repente haga un tutorial de como comenzar en este mundo del EVENT SOURCING solo háganmelo saber y veré que hago para ayudar. Aunque les soy sincero, yo que ya estoy usando y viendo las maravillas del EVENT SOURCING todavía me queda mucho por aprender, pero por eso ¡NUNCA PARES DE APRENDER!.
Interesante articulo Nestor, me gustaría poder ver mas acerca de este tipo de tendencias en platzi, no estaría mal que pudieras mostrarnos un tutorial para poder tener un acercamiento mayor de este tema.
Las bases de datos de eventos, para ser manejadas necesitan que uno aprenda nuevos conceptos, de hecho, a mí me paso que todo lo que sabía de CRUD en bases de datos relacionales apenas me serbia para hacer comparaciones que al final no me ayudaban mucho al contrario me confundían más.
Es en si una ¡nueva forma de pensar!, con conceptos que poco tienen que ver con lo que se maneja en el mundo relacional. Conceptos como aggregates, rehidratación, condición de carrera, comandos, eventos, ids de correlación, proyecciones, snapshops, checkpoints, sagas, etc. Me hicieron volar la cabeza.
Me acuerdo de que lo primero que pregunte es ¿Cómo hago un insert, update o un delete en las tablas? La respuesta fue: “NO EXISTEN tablas, solo eventos”, entre en shock jajajaja.
Al final mirando en retrospectiva veo como tuve que desaprender conceptos que para mí eran universales, como mis tan amadas tablas con sus filas, columnas y sus procedimientos almacenados, etc. Hasta ese entonces no entendía como se puede guardar algo que no sea en una tabla, ¿Cómo recupero las filas de clientes? ¿Cómo agrupo los eventos?, ¿Cómo quito de los eventos las ventas del mes?, y un montón de “Cómo esto y aquello”.
En fin, lo que te puedo decir es que vale la pena y lo vale mucho. Voy a ir viendo como puedo ir haciendo minitutoriales que ilustren este interesante mundo de EventSourcing, dependiendo claro esta del interés de la gente, porque como es un patrón de diseño tan disruptivo, comprendo no sea tan popular en un mundo dominado por las bases de datos relacionales.
No había escuchado antes de esto, no logro entender muy bien en que consiste pero me gustaría saber más de este tema ya que las bases de daros son mi pasión ^_^.
Gracias. Interesante artículo.
Súper interesante, espero poder tutoriales en el futuro.
Que interesante blog yo si quisiera conocer mas sober el mundo del Event Sourcing. Esperare tu tutorial !!
Interesante articulo, espero sigas publicando material sobre el tema, … y porque no un curso del mismo. Gracias
Gracias por la información, sería bueno que nos indiques si hay algún curso en Platzi que profundice un poco en este conocimiento, con el fin de pasar a la práctica de la mano de los expertos.
Que yo sepa, todavía no hay ningún curso.
@nestornjrz, gracias, quedo pendiente y ojalá Platzi lo tome como sugerencia para un curso!
Muy buen artículo, comenzaré a preguntarles a los dichosos “DBA” si saben lo que es el EVENT SOURCING. Solo para cuestionarlos. 👀
Los DBA no deberían preocuparse porque las bases de datos de eventos no reemplazan a las bases de datos relacionales, solo que las coloca en un segundo plano. Las bases de datos de eventos se convierten, según la jerga EventSourciana (si se puede usar el termino), en la “fuente de la verdad” y las bases de datos relacionales pasan a usarse como proyecciones estructuradas de los eventos, para fines analíticos y de reportes.
Una cosa si pasa, las funciones, los procedimientos almacenados y los triggers que se usan mucho en el mundo relacional prácticamente ya no se utilizan. Sin embargo no es una perdida total para los DBA, porque pierden eso, pero ganan un espectacular log de auditoria de lujo, donde van a saber exactamente que se modificó, cuando se modificó, quien modifico, desde que IP, desde que geolocalización y un montón de metadatos más, en el orden exacto en que ocurrieron, y ni hablar de los desarrolladores, es una delicia para encontrar errores más fácilmente, porque todo se guarda, literalmente nada se pierde.
Hola! muy interesante articulo las bases de datos continuan siendo efectivas pero hay que conseguir actualizadas. eso es muy importante ya que hay muchas bases viejas en internet
Ganas de aprender backend mode: ON
Wow increible articulo, no sabia muchas cosas de las que nos compartiste 👏👏
Nestor, excelente la información. Gracias por compartir.
Gracias Nestor por el artículo, desconocía todo sobre EVENT SOURCING ,sería genial que escribas o realices un video sobre este tema. Por mi parte estaré investigando para conocer más del mundo de EVENT SOURCING.
En ingles hay más información, pero en español es prácticamente nula y críptica. Lo cual me extraña porque es un patrón de diseño que “destranca” mucho la rigidez que se ve en el modelado de las bases de datos relacionales.
Cuando diseñas un DER (diagrama de entidad relación) encuentras que una vez establecidas relaciones entre las tablas, las mismas se convierten en ley y cuando mas tablas relacionadas vas teniendo, mas complejo se vuelve añadirle características al o los programas que dependen de esa base de datos. ¡Y ni que decir si alguien no normalizo correctamente las tablas y ya se usan en producción, chau! Se empiezan a llenar de tablas auxiliares que repiten datos y solo las personas que las diseñaron saben que campos se usan para hacer la correcta relación con las demás tablas.
Si a eso le sumas los procedimientos almacenados, funciones de base de datos personalizadas y triggers, te encuentras con que te “casaste” con esa base de datos. Y olvídate del control de código (por lo menos uno centralizado), porque por un lado tienes lógica de negocios en la base de datos y por otro tienes lógica de negocio en el código fuente de la aplicación que maneja la base de datos.
Aguanté MariaDB
yo uso excel eso cuenntA? hhahaa
gracias nestos por tu artyiculo que interesante me gustaria saber mas de esto que debo aprender como base para comprenderlo me ayudas XD¡¡¡¡
Es interesante en serio el mundo de las bases de datos; mas sin embargo de pronto por mi inexperiencia he querido saber, yo entiendo como subir datos actualizarlos y todo lo demás tanto en MySQL como en Firestore, pero, ¿existe alguna manera de relacionar mi base de datos desde la página principal de una página web que tengo con una base de datos que haya diseñado previamente en Firesotore o en SQL?, o que esta se importe a un excel para luego ser importada a Firestore; solo encuentro plugins costosos que hay que ponerle a las páginas para que te deje importar esso datos
Interesante, en espera del tutorial. ❤️
En tu diagrama tienes “recepcionista”. Cuidado con eso, se pierda seriedad sobre lo que se expone con esos detalles.