16 Mar 2015

SQL y NoSQL

SQL y NoSQL
Mira a tu alrededor, estas rodeado de gente con diferentes características. La mayoría de ellas se pueden agrupar bajo ciertas etiquetas, es decir, todas ellas tienen un nombre y edad, aunque cada una distinto al de los otros. Cuando consigues identificar esa relación, puedes tener esos datos en una base de datos Relacional. Como el nombre (y el ejemplo) sugiere, esto es por que todos los elementos (registros, o en el ejemplo, personas) de la base guardan relación entre sí.

Siguiendo, las personas que ves viven en algún lugar, con esa información podemos abstraer una estructura de una base de datos como esto:

Donde estamos definiendo que una persona sólo puede vivir en una ciudad, pero en una ciudad viven muchas personas.

Debido a que las bases relacionales tienen ya más de 30 años de desarrollo, la mayoría de los esquemas la utilizan, cualquier ejemplo que puedas pensar seguro caerá en este modelo. El problema de este tipo de bases es cuando, rompemos el modelo. 

¿Que pasa si, queremos almacenar un dato en el que no pensamos desde el principio? Ahora, necesitamos guardar donde trabajan estas personas. Lo más probable es que no todas ellas tengan un empleo.

Las bases relacionales, solucionan esto normalizando los datos. Es decir, agregan la referencia nueva a todos los elementos aunque no tengan un dato.

Si tuvieras ya una lista de un millón de personas, ¿cuanto te llevaría guardar el dato de su empleo para los que las tengan y para los que no?.

Ese tipo de operaciones es una de las desventajas de las bases relacionales, por que, en el mundo real, no todos los modelos en que se piensan cubren realmente el patrón.

Bajo esa perspectiva surge NoSQL (Not Only SQL), que básicamente parte de poder almacenar cada elemento con su propia estructura según las necesidades.

Volviendo al ejemplo, antes de pensar en guardar el empleo de las personas tenemos una serie de datos asi:
Persona 1 {Nombre: "Juan",Ciudad: "Mexico"}
Persona 2 {Nombre: "Pepe",Ciudad: "Cancún"}
Persona 3 {Nombre: "Toño",Ciudad: "Puebla"}
Todos los datos están 'normalizados', si agregamos el empleo en una base relacional tendríamos espacio desperdiciado:
Persona 1 {Nombre: "Juan",Ciudad: "Mexico",Trabajo:""}
Persona 2 {Nombre: "Pepe",Ciudad: "Cancún",Trabajo:"AAA S.A."}
Persona 3 {Nombre: "Toño",Ciudad: "Puebla",Trabajo:""}

Mientras que, usando un modelo NoSQL, cada elemento se adapta según su contenido:
Persona 1 {Nombre: "Juan",Ciudad: "Mexico"}
Persona 2 {Nombre: "Pepe",Ciudad: "Cancún",Trabajo:"AAA S.A."}
Persona 3 {Nombre: "Toño",Ciudad: "Puebla"}

Esto hace que la modificación de la estructura definida en un principio, sea mucho más fácil de actualizar, y por tanto, la base de datos será más simple de mantener.

Artículos relacionados