The relational model is dead, SQL is dead,

and I don’t feel so good myself

por Diana de la Costa

En este tópico se considera, por un lado, el tipo y volumen de la data; y por el otro, una
mayor población de usuarios prospectos. Estos dos frentes han abierto la necesidad de
otras formas no convencionales para manejar y acceder a la data. Las nuevas propuestas
surgidas han producido una nueva generación para la gestión de datos, fundamentalmente
no relacionales, para aplicaciones de gran escala en las que la tecnología de base de datos
tradicional ya no es satisfactoria. Así aparece el término “NoSQL” que engloba a las
tecnologías no relacionales.

Hay que distinguir entre el modelo relacional y su respectivo lenguaje de consulta “SQL”,
por una parte, y el sistema de gestión de base de datos relacionales, por otra parte. El
modelo relacional y “SQL” fueron inventados para tareas administrativas con data bien
estructurada, sin embargo, actualmente las aplicaciones de gestión de datos son más
diversas y con ello emerge “NoSQL” para data no estructurada.

Ante el mayor volumen de datos, el sistema de data relacional se deriva a servidores más
grandes y poderosos, en cambio, el sistema de data “NoSQL” se distribuye entre diferentes
hosts para más flexibilidad de gestión de la data y menos costos para escalamiento. Las
aplicaciones de gestión de datos se han vuelto más complejas y ya no pueden servirse de
un solo tipo de modelo y lenguaje; y en cuanto a modelo se refiere el sistema “NoSQL”
brinda más simplicidad operativa.

A pesar de la investigación y desarrollo, el modelo relacional y “SQL” pueden no ser una

buena base para gestionar diversidad de data y workload. De esta forma, aparece la
dualidad entre preferencias y estructuras de la data para objetos complejos versus una data
completamente sin estructura, ante lo cual es necesario el establecimiento de un estándar
que apoye la interoperabilidad y traducción dada la simplicidad de operaciones y casi
ausencia de esquemas.

Al parecer, el actual sistema “NoSQL” no distingue entre sistema lógico y físico, lo que hace
complicado poder definir un estándar para independencia de datos y el mantenimiento de
estos. Guardar objetos tal como fueron programados niega el requerimiento de
independencia de datos dirigidos al sistema “NoSQL”, donde las restricciones de la base de
datos son muy relajadas o nulas (en “SQL” es altamente restrictivo).

Aunque no haya esquema para los datos “NoSQL”, aún es posible que los objetos
pertenezcan a ciertas clases cuyas definiciones aparecen en los programas. A su vez es
imprescindible la flexibilidad, así que debería apoyarse el polimorfismo de clases y de esta
manera es que una alta disponibilidad de representatividad de los datos es fundamental
para su fácil gestión.

Con esta nueva disponibilidad de la data nace la duda de si las propiedades ACID siguen
siendo importantes para la consistencia de la base de datos (sin confundir esto con la
estructura del modelo relacional). Sin embargo, estas continúan siendo esenciales para la
mayoría de los sistemas operacionales y de procesamiento de transacciones en línea.

Y a pesar de las deficiencias del modelo relacional y “SQL”, estos siguen siendo fuertes
porque han demostrado que funcionan, y coexisten con las bases de datos “NoSQL” en esta
era de gran volumen de data, descentralización y heterogeneidad de dispositivos y data
fuera de control. Las bases de datos “NoSQL” son apropiadas para aplicaciones que no
requieren de propiedades ACID o para tratar con objetos pobremente representados de
manera relacional. Así, el almacenamiento de datos “NoSQL” aparece como opción
adicional para completar el surtido de servicios de almacenamiento en las empresas.