SQL o NoSQL: qué te están preguntando y qué deberías responder

En algún momento de la primera reunión técnica de un proyecto nuevo, alguien te pregunta si prefieres «una base de datos relacional o una NoSQL». Lo dice con naturalidad, como quien pregunta si el logo va en la esquina o en el centro, y espera que decidas. La verdad es que casi nadie fuera de un equipo técnico sabe qué se le está pidiendo, y menos aún que esa respuesta va a acompañar al proyecto durante años, no durante la reunión.

Se puede responder bien sin saber programar, siempre que se entienda qué diferencia hay de verdad entre las dos opciones y qué se juega tu negocio en cada una.

#La diferencia, en una imagen

Piensa en dos formas de llevar el archivo de una empresa. La primera es un armario de carpetas idénticas: cada carpeta tiene las mismas diez pestañas —nombre, fecha, importe, cliente— en el mismo orden, así que cualquiera que abra cualquier carpeta sabe exactamente dónde va a encontrar cada dato. Eso es, a grandes rasgos, una base de datos relacional, la que se conoce como SQL: todo encaja en una tabla con columnas fijas, y cada carpeta es una fila que respeta esas columnas.

La segunda es una caja de fichas sueltas. Cada ficha puede tener sus propios apartados: la de un cliente lleva teléfono y dirección, la de un pedido lleva artículos y cantidades, y ninguna tiene por qué parecerse a la de al lado. Eso es, a grandes rasgos, una base de datos NoSQL: cada ficha —a la que en la jerga técnica se le llama registro— puede tener su propia forma, sin obligación de encajar en una plantilla común.

Ninguna de las dos es superior. Son dos maneras distintas de guardar información, pensadas para necesidades distintas.

#Qué gana cada una

La base de datos relacional gana en dos cosas que casi todo negocio necesita sin saber que las necesita: consistencia y capacidad de cruzar información. Consistencia quiere decir que si un pedido apunta a un cliente que no existe, el sistema lo rechaza antes de que ese error entre en tus números. Cruzar información quiere decir que puedes preguntar, con una sola consulta, «qué clientes de Madrid han hecho pedidos por más de mil euros este trimestre», y obtener la respuesta exacta, aunque esos datos vivan en tablas distintas.

La base de datos NoSQL gana en volumen y en flexibilidad de estructura. Aguanta mejor cantidades enormes de información repartida entre muchas máquinas, y admite que cada registro cambie de forma sin tener que rediseñar nada. Es la opción pensada para cuando los datos no tienen relaciones fuertes entre sí y llegan en cantidades que desbordarían un archivo tradicional: registros de actividad, mensajes sueltos, eventos que se guardan y casi nunca se cruzan entre ellos.

#Lo que de verdad cuesta cambiar de idea después

Esta decisión pesa más de lo que parece en el momento de tomarla porque no es fácil de deshacer — la misma atadura, con otro nombre, que ya aparece al elegir un framework: lo que ahorra tiempo al principio condiciona lo que se puede hacer después. Una base de datos es la estructura sobre la que se ha construido cada pantalla, cada informe y cada integración con otros programas, no un color de fondo que se cambia en una tarde. Si a los dos años el negocio descubre que necesita cruzar información que nunca pudo cruzar bien, o al revés, que el volumen de datos ha desbordado lo que su sistema relacional aguanta con comodidad, el cambio no consiste en «mover los datos a otro sitio»: consiste en rehacer buena parte de cómo la aplicación entera habla con sus datos.

Ese trabajo se mide en meses, no en días, y casi siempre convive un tiempo con el sistema antiguo funcionando en paralelo, porque parar el negocio mientras se migra no suele ser una opción. Es exactamente el tipo de coste oculto que no aparece en la reunión donde se decide el tipo de base de datos, y que solo se hace visible cuando alguien tiene que pagarlo.

#Un negocio puede usar las dos a la vez

Elegir no siempre significa quedarse con una sola para siempre. Es habitual, y sensato, que un mismo negocio use una base de datos relacional para todo lo que tiene relaciones claras —clientes, pedidos, facturas, stock— y reserve una NoSQL para una pieza concreta que encaja mejor ahí: por ejemplo, un historial de eventos de actividad que crece sin parar y que casi nunca hace falta cruzar con nada más. Lo importante no es jurar fidelidad a una sola tecnología, sino que cada tipo de dato viva en el sistema pensado para su forma y su volumen, y que esa decisión se tome con criterio, no por costumbre ni por moda.

#La advertencia principal

La inmensa mayoría de los negocios necesitan lo primero —una base de datos relacional— y sin embargo, en los últimos años, un número considerable ha terminado eligiendo lo segundo. No porque su proyecto lo pidiera, sino porque NoSQL sonaba más moderno, más preparado para crecer, más «a prueba de futuro». La consecuencia habitual, meses después, es un equipo escribiendo a mano, en el propio código de la aplicación, comprobaciones que una base de datos relacional habría hecho sola desde el primer día: que un pedido no apunte a un cliente inexistente, que un importe no se quede huérfano de su factura.

#Si tus datos se cruzan entre sí, la respuesta ya está tomada

Si tus datos tienen relaciones entre sí —clientes que hacen pedidos, pedidos que tienen líneas, líneas que apuntan a productos de un catálogo— vas a querer cruzarlos tarde o temprano: cuánto ha comprado cada cliente, qué producto se agota antes, qué pedidos llevan retraso. Cruzar información con precisión y sin errores es exactamente para lo que se diseñó una base de datos relacional. Si en cambio tus datos son piezas sueltas sin relación fuerte entre ellas y llegan en volúmenes que rompen cualquier archivo tradicional, ahí empieza a tener sentido lo otro.

#Cómo llegar a la respuesta por descarte

1. ¿Necesito cruzar información entre distintos tipos de datos? Si la respuesta es sí —y en la mayoría de negocios lo es—, empieza a inclinar la balanza hacia lo relacional.
2. ¿Qué pasa si un dato queda mal enlazado? Si un error así te puede costar dinero o un disgusto con un cliente, quieres un sistema que lo impida de raíz, no que confíe en que nadie se equivoque.
3. ¿De verdad voy a manejar un volumen que un archivo tradicional no aguante? La mayoría de negocios, incluso los que se sienten grandes por dentro, no llegan ni de lejos a esa cifra.

La respuesta correcta suele ser la aburrida: una base de datos relacional, bien diseñada desde el principio. No es la que más titulares genera en una charla de tecnología, pero es la que menos sorpresas da cuando, dentro de dos años, alguien pregunte algo tan simple como «cuánto llevamos vendido a este cliente» y espere una respuesta exacta, no una aproximación construida a mano.