SQL vs No-SQL

<aside> <img src="/icons/database_blue.svg" alt="/icons/database_blue.svg" width="40px" /> SQL

• BD sencillas
• BD con pocas solicitudes
• Muchas escrituras
• Hay Tablas
• En las tablas, hay filas </aside>

<aside> <img src="/icons/database_green.svg" alt="/icons/database_green.svg" width="40px" /> No-SQL

• BD complejas
• BD con muchas solicitudes
• Muchas lecturas
• Hay Colecciones
• En las colecciones hay Documentos </aside>

¿Cómo se modelan las BD No-SQL?

Antes que nada, ten en cuenta que Colección y BD es lo mismo para No-SQL.

Por ejemplo, supongamos que tenemos una BD con posts de un usuario.

Así modelariamos una BD No-SQL

Posts: {
	title: string,
	desc: string,
	created_at: Date,
	user: {
		id: string,
		name: string,
		avatar: string,  //Será una URL
},

Para modelar la BD de usuarios…

Users: {
	name: string,
	email: string,
	password: string,
	salt: string, //Para encriptar la contraseña del usuario
}

El problema aquí es que cuando un usuario quiera actualizar su nombre de usaurio, tendremos que modificar toda la BD de posts para actualizar el nombre también…

Para solucionar esto, tenemos dos opciones:

1. Usar el write batch (también se conocen como transacciones).
   • Si hay algún error cuando en la BD de Usuarios se quiera actualizar el nombre de un usuario, entonces la BD de posts no hará nada. Y viceversa, si se actualiza bien la BD de usuarios pero la de Posts no, no se cambia nada. O se actualizan las dos o ninguna, no habrán inconsistencias.
2. En vez de duplicar datos, guardar el ID del usuario en los post. El problema de esto es que ahora siempre necesitaremos 2 consultas en vez de 1 para obtener todos los datos. Pero no tendremos que lidiar con tener que sincronizar todos los datos con cada cambio.

Cuando trabajamos con una BD con muchos datos, se suele usar la paginación, donde mostramos solo unos pocos documentos, 10 por ejemplo y el usuario va solicitando los siguientes 10, y ldespués 10 más, etc.