Title: comparativa entre NoSQL y SQL
Course: 2025 - LISI - Desarrollo Web I 3-2 > Section: Nuevas Tecnologías Web

Resumen sobre la comparativa entre NoSQL y SQL

 | Bases de datos SQL | Bases de datos NoSQL
Historia sobre el desarrollo | Se desarrollan a finales de la década de 1970 para respaldar la primera ola de aplicaciones de almacenamiento de datos. | Se desarrollan a finales de la década de 2000 para superar las limitaciones de las bases de datos SQL, sobre todo en lo relativo a escalabilidad, datos multiestructurados, distribución geográfica y sprints de desarrollo ágiles.
Ejemplos | MySQL, Postgres, Microsoft SQL Server, Oracle Database. | MongoDB, Cassandra, HBase, Neo4j.
Modelo de almacenamiento de datos | Los registros individuales (p. ej., «empleados») se almacenan en filas de tablas, y cada columna almacena un dato específico sobre ese registro (p. ej., «director», «fecha de contratación», etc.) al estilo de las hojas de cálculo. Los datos relacionados se almacenan en tablas separadas, y luego se combinan cuando se ejecutan consultas más complejas. Por ejemplo, «oficinas» se puede almacenar en una tabla y «empleados», en otra. Cuando un usuario quiere encontrar la dirección de trabajo de un empleado, el motor de la base de datos une las tablas «empleado» y «oficina» para obtener toda la información necesaria. | Varía en función del tipo de base de datos. Por ejemplo, los almacenes de clave-valor funcionan de forma parecida a las bases de datos SQL, pero solo tienen dos columnas («clave» y «valor»), con información más compleja, que a veces se almacena como objetos BLOB en las columnas «valor». Las bases de datos de documentos evitan por completo el modelo de tablas y filas, almacenando todos los datos relevantes juntos en un único documento en formato JSON, XML u otro formato, que puede anidar valores de forma jerárquica.
Esquemas | La estructura y los tipos de datos se establecen de entrada. Para almacenar información sobre un nuevo dato, se debe modificar toda la base de datos, que deja de funcionar durante este tiempo. | Suelen ser dinámicos, y en ocasiones es necesario aplicar algunas reglas de validación de datos. Las aplicaciones pueden ir añadiendo nuevos campos según convenga y, a diferencia de lo que ocurre con las filas de las tablas SQL, en caso necesario se pueden almacenar juntos datos de naturaleza diferente. Para algunas bases de datos (como las orientadas a columnas), resulta un poco más complicado añadir nuevos campos de forma dinámica.
Escalabilidad | Escalado vertical, es decir, es necesario añadir más potencia a un único servidor en caso de que aumente la demanda. Es posible repartir las bases de datos SQL por diferentes servidores, pero es una tarea que requiere una participación importante del equipo de ingeniería, y suelen perderse funcionalidades relacionales básicas como las operaciones JOIN, la integridad de las referencias y las transacciones. | Escalado horizontal, es decir, para aumentar la capacidad, el administrador de la base de datos solo tiene que añadir servidores básicos o instancias de la nube. La base de los datos distribuye los datos en los servidores según las necesidades.
Soporta transacciones ACID* de registros múltiples | Sí | Generalmente no.
Manipulación de datos | Lenguaje específico que utiliza instrucciones Select, Insert y Update, p. ej., SELECT fields FROM table WHERE... | A través de APIs orientadas a objetos
Coherencia | Se puede configurar un nivel de consistencia elevado | Consistencia débil

*https://databricks.com/glossary/acid-transactions