Las tecnologías cambian día a día. En lo que respecta a mecanismos de persistencia, el advenimiento de las bases de datos no relacionales ha representado una alternativa distinta respecto a sus pares relacionales. Ahora, mucho se ha hablado respecto a ellas, tanto para bien como para mal. ¿Son seguras y confiables? Discutamos un poco respecto a lo que se dice, e intentemos llegar a una conclusión.
Las bases de datos relacionales surgen como una solución ante la necesidad de persistencia de datos. No pasó mucho tiempo hasta que se formaran estándares sólidos en su utilización, como por ejemplo el lenguaje de consultas SQL (Structured Query Language) y los modelos relacional y entidad-relación como herramientas para modelado de bases de datos. Sin embargo los años pasan, y nuevas alternativas surgen para buscar soluciones a problemas ya existentes. Justamente, estó pasó con las bases de datos relacionales: surgió algo nuevo para intentar mejorar puntos débiles.
Se empezó a hablar de ellas a finales de los '90. Su crecimiento y adopción vertiginosa se debió a que buscaban obtener mejores resultados que sus predecesoras en problemáticas específicas, como por ejemplo obtener grandes volúmenes de información procesada. Ahora, la coherencia y demás beneficios que pudiera proveer una base de datos relacional se veían relegados a un segundo plano gracias a lo que la demanda indicaba. No todo fue color de rosas, y por momentos el ACID era sólo un preferible.
¿Qué es eso del broken by design?
La utilización de bases de datos no relacionales representó un punto positivo en la solución de problemas complejos ya existentes. Ahora, estas soluciones tenían un precio: se podía por ejemplo lograr una gran versatilidad en el procesamiento de los datos almacenados, pero se perdía algo de performance (en comparación con las bases de datos convencionales), o no se tenía un buen modelo de consultas concurrentes. Este punto no es un detalle menor, ya que directamente podría afectar a la seguridad del sistema (así sucedió con el ataque por el que el servicio Flexcoin sufrió grandes pérdidas monetarias y finalmente quebró).
Se empezó a utilizar el concepto de “broken by design” para hablar de la nueva tecnología, alegando algo así que este tipo de mecanismos de persistencia tenía fallas críticas desde el momento en que fueron pensadas.
¿Y qué hay con todo esto?
Las herramientas son simplemente medios para lograr objetivos. No son buenas o malas en sí; en todo caso, serán más o menos adecuadas para una tarea en particular. Justamente, lo mismo pasa con los mecanismos de persistencia citados. Comparar una con otra no debería tener más finalidades que simplemente determinar si soluciona mejor un problema específico a resolver.
Por todo esto, tal vez decir que una herramienta tiene sus falencias de forma crítica e irremediable, que está broken by design o averiada desde su concepción, es algo no acertado. Sí es cierto que quizás en sus primeras versiones, las herramientas no suelen tener su mejor forma. Pero con el tiempo se buscará mejorarlas.
Más allá de esto, no debemos olvidar la finalidad de una tecnología de persistencia: almacenar información. Las elecciones de qué información almacenar, en qué forma, bajo qué contexto y con cuánta demanda posible, dependerán completamente de nosotros. Simplemente debemos elegir las herramientas correctas.
