SQL vs NoSQL: cómo elegir

Las características de una y otra son:

Bases de datos SQL:

• Almacena datos relacionados en las tablas
• Requiere un esquema que defina las tablas antes de su uso
• Fomenta la normalización para reducir la redundancia de datos
• Tabla de soporte JOIN para recuperar datos relacionados de varias tablas en un solo comando
• Aplica las reglas de integridad de datos
• Posibilidad de escalar
• Utiliza un lenguaje declarativo de gran alcance para las consultas
• Ofrece apoyo, experiencia y herramientas.

Bases de datos NoSQL:

• Almacena datos relacionados en JSON-like
• Puede almacenar datos sin especificar un esquema
• Por lo general se deben “desnormalizar” por lo que la información sobre un artículo está contenido en un solo documento
• No debe requerir JOINs (suponiendo que se utilizan los documentos desnormalizados)
• Permite guardar cualquier dato, en cualquier lugar, en cualquier momento y sin verificación
• Garantiza cambios en un documento único - pero no en múltiples documentos
• Proporciona un excelente rendimiento y escalabilidad
• Utiliza objetos JSON para consultas de datos
• Es una tecnología más reciente.

Las bases de datos SQL son apropiadas para proyectos en que los requisitos se pueden determinar, y la robustez de la integridad de los datos es esencial. Las bases de datos NoSQL son apropiadas para las necesidades de datos no relacionados, indeterminados o en evolución, donde la velocidad y la escalabilidad son más importantes. En términos más simples:

• SQL es digital. Funciona mejor para elementos claramente definidos, discretos con especificaciones exactas. Casos de uso típicos son las tiendas online y sistemas bancarios.
• NoSQL es analógica. Funciona mejor para los datos orgánicos con requerimientos fluidos. Casos de uso típicos son las redes sociales, gestión de clientes y sistemas de análisis web.

Pocos proyectos tendrán un ajuste exacto. Cualquiera de estas opciones podría ser viable si tienes datos más superficiales o eliminaras la normalización de forma natural. Pero ten en cuenta estos escenarios de ejemplo simplificado con generalizaciones. Ten en cuenta los pros y los contras en el inicio del proyecto y no irá mal.

Escenario uno: una lista de contactos

Vamos poner en práctica un sistema de libreta de direcciones basada en SQL. Nuestra tabla inicial de contactos se define con los siguientes campos:

• Id
• título
• nombre
• apellido
• sexo
• teléfono
• correo electrónico
• dirección 1
• dirección 2
• dirección 3
• ciudad
• provincia
• código postal
• país

Problema 1: pocas personas tienen un solo número de teléfono. Probablemente necesitemos al menos tres campos para teléfono fijo, móvil y trabajo, pero no importa cuántos asignamos - alguien, en algún momento va a querer más. Vamos a crear una tabla separada teléfono para que los contactos puedan tener tantos como quieran. Esto también normaliza nuestros datos - no necesitamos un NULL para contactos sin número:

• contact_id
• nombre (texto, como línea fija, móvil, trabajo, etc.)
• número

Problema dos: tenemos el mismo problema con las direcciones de correo electrónico, así que vamos a crear una tabla parecida para email:

• contact_id
• Nombre (texto, como email casa, email trabajo, etc.)
• dirección

Problema tres: es posible que no desees introducir una dirección (geográfica), o podemos querer introducir varias direcciones para el trabajo, el hogar, casa de vacaciones, etc. Por lo tanto, necesitamos una nueva tabla de direcciones:

• contact_id
• Nombre (texto, como domicilio, oficina, etc.)
• Dirección 1
• Dirección 2
• dirección 3
• ciudad
• provincia
• código postal
• país

La tabla de contactos original se ha reducido a:

• Identificación
• título
• nombre
• apellido
• sexo

Disponemos de una base de datos normalizada que puede almacenar cualquier cantidad de números de teléfono, direcciones de correo electrónico y direcciones de cualquier contacto.  Desafortunadamente...

El esquema es rígido
No hemos contemplado fecha de nacimiento, empresa o puesto de trabajo. No importa cuántos campos añadamos, pronto recibimos solicitudes de actualización de la tabla para añadir notas, aniversarios, cuentas de redes sociales, etc. Es imposible prever todas las opciones, por lo que posiblemente creemos otra tabla para hacerle frente.

Los datos son fragmentados
No es fácil para los desarrolladores o administradores de sistemas examinar la base de datos. La lógica del programa también será más lenta y compleja, ya que no es práctico recuperar datos de un contacto en una sola declaración SELECT con múltiples  cláusulas JOIN (el resultado contendría cada combinación de teléfono, correo electrónico y dirección: si alguien tiene 3 números de teléfono, 5 correos electrónicos y 2 direcciones, la consulta SQL generará treinta resultados.)

Por último, la búsqueda de texto completo es difícil. Si alguien busca "Imaginanet", debemos comprobar las cuatro tablas para ver si es parte de un nombre de contacto, teléfono, correo electrónico o dirección y clasificar el resultado en consecuencia.

La alternativa NoSQL

Nuestros datos de contacto se refieren a personas. Ellos son impredecibles y tienen necesidades diferentes en diferentes momentos. La lista de contactos se beneficiaría del uso de una base de datos NoSQL, que almacena todos los datos acerca de un individuo en un solo documento en la colección contactos:

  {
  name: [
    "Billy", "Bob", "Jones"
  ],
  company: "Fake Goods Corp",
  jobtitle: "Vice President of Data Management",
  telephone: {
    home: "0123456789",
    mobile: "9876543210",
    work: "2244668800"
  },
  email: {
    personal: "bob@myhomeemail.net",
    work: "bob@myworkemail.com"
  },
  address: {
    home: {
      line1: "10 Non-Existent Street",
      city: "Nowhere",
      country: "Australia"
    }
  },
  birthdate: ISODate("1980-01-01T00:00:00.000Z"),
  twitter: '@bobsfakeaccount',
  note: "Don't trust this guy",
  weight: "200lb",
  photo: "52e86ad749e0b817d25c8892.jpg"
}

En este ejemplo, no hemos guardado el título del contacto o el sexo, y hemos añadido datos innecesarios para otra persona. No importa, podemos añadir o eliminar campos a voluntad.

Dado que los datos del contacto están contenidos en un solo documento, podemos recuperar parte o toda la información usando una sola consulta. Una búsqueda de texto completo es también más sencilla; en MongoDB podemos definir un índice en todos los campos de texto de contactos utilizados:

db.contact.createIndex({ "$**": "text" });

A continuación, buscamos un texto completo utilizando:

db.contact.find({
   $text: { $search: "something" }
 });

Escenario dos: una Red Social

Una red social utiliza un almacenamiento de datos similar, pero se amplía en el conjunto de características con opciones tales como vínculos de relación, actualizaciones de estado, mensajes y "me gusta". Estas características pueden implementarse y dejarlos en respuesta a las demandas de los usuarios - es imposible predecir cómo van a evolucionar.

Además:

• La mayoría de las actualizaciones de datos tienen un solo punto de origen: el usuario. Es poco probable que necesitemos actualizar dos o más registros a la vez, por lo que no se requiere la funcionalidad de transacciones similares.
• A pesar de lo que algunos usuarios pueden pensar, una actualización de estado fallida es poco probable que cause un colapso global o pérdida financiera. La interfaz y el rendimiento de la aplicación tienen una prioridad mayor que robustece la integridad de los datos.

NoSQL parece ser una buena opción. La base de datos nos permite implementar rápidamente las características de almacenamiento de diferentes tipos de datos. Por ejemplo, todas las actualizaciones de estado de fecha del usuario podría ser colocado en un documento único en la colección estado:

{
   user_id: ObjectID("65f82bda42e7b8c76f5c1969"),
   update: [
     {
       date: ISODate("2015-09-18T10:02:47.620Z"),
       text: "feeling more positive today"
     },
     {
       date: ISODate("2015-09-17T13:14:20.789Z"),
       text: "spending far too much time here"
     }
     {
       date: ISODate("2015-09-17T12:33:02.132Z"),
       text: "considering my life choices"
     }
   ]
 }

 Si bien este documento podría ser largo, podemos buscar un subconjunto de la matriz, como por ejemplo la actualización más reciente. El estado de la historia completa de cada usuario también se puede buscar rápidamente.

Ahora suponemos que queremos introducir una opción emoticono al publicar una actualización. Habría que añadir una referencia gráfica a las nuevas entradas en la actualización de la matriz. A diferencia de una tienda en SQL, no es necesario crear mensajes de emoticonos anteriores con NULL - nuestra lógica del programa puede mostrar una imagen predeterminada o ninguna imagen si un emoticono no se ha establecido.

Escenario tres: un Sistema de Gestión de Almacenes

Considera un sistema que controla los bienes almacenados. Necesitamos registrar:

• Los productos que llegan al almacén y son asignados a un lugar/almacén específico
• Los movimientos de mercancías en el almacén, por ejemplo, la reordenación de stock por lo que los mismos productos se encuentran en lugares adyacentes
• Las órdenes y la posterior eliminación de los productos del almacén de entrega.

Nuestros requisitos de datos:

1. La información de producto genérica, como cantidades de cajas, dimensiones o el color, se pueden almacenar. Es poco probable que se ocupen de aspectos específicos, tales como la velocidad del procesador portátil o la vida estimada de la batería del smartphone.
2. Es imperativo minimizar los errores. No podemos tener productos que desaparecen o productos que son trasladados a un lugar donde ya se están almacenando otros productos diferentes.
3. En su forma más simple, estamos recogiendo la transferencia de elementos de un espacio físico a otro - o llevar de la ubicación A y colocarla en el lugar B. Eso son dos versiones de la misma acción.

Necesitamos una tienda robusta con la integridad de datos fuerte y soporte de transacciones. Sólo una base de datos SQL (actualmente) puede satisfacer estos requisitos.