KriaturasBases de datos para quien empieza

Parte V · Horizonte

Capítulo 15 — Más allá de las tablas (NoSQL, IA y fundamentos)

Al acabar este capítulo sabrás que las tablas no son la única forma de guardar datos, conocerás de pasada las familias de bases de datos que existen más allá del modelo relacional, y tendrás claro por qué entender los fundamentos te convierte en quien manda sobre la herramienta —y no al revés.

Has llegado al final. Y al final no toca aprender una orden nueva de SQL ni una tabla más. Toca subir a una colina, darte la vuelta y mirar todo el camino que has recorrido.

Porque has hecho algo grande. Empezaste en el capítulo 1 con una libreta que se te iba de las manos, y has terminado diseñando la base de datos completa de un juego: jugadores, cartas, mazos, partidas, amistades, intercambios. La has ordenado para que no haya datos repetidos, la has blindado con reglas que se cumplen solas, has aprendido a exprimirla con consultas, a protegerla con transacciones y a acelerarla con índices. Todo eso, con tablas.

Y aquí viene la pregunta que cierra el libro: ¿y si te dijera que no todo el mundo guarda los datos así?


Lo que las tablas hacen de maravilla (y por qué siguen mandando)

Antes de mirar fuera, recordemos por qué el modelo relacional se ganó su trono.

Todo lo que has aprendido —tablas con filas y columnas, claves primarias y foráneas, SQL, integridad, transacciones— forma el modelo relacional. Es, con diferencia, el estándar más usado del mundo para guardar datos, y lleva décadas siéndolo. No es moda: es que resuelve increíblemente bien el problema más común.

¿Qué problema? Datos estructurados (que tienen siempre la misma forma: un jugador siempre tiene alias, email y fecha de alta) y muy relacionados entre sí (jugadores que poseen cartas, que arman mazos, que juegan partidas). Para eso, las tablas son imbatibles: te dan un esquema claro, te garantizan que los datos son coherentes y te dejan cruzarlos con consultas tan potentes como quieras.

La mayoría de las apps, webs y juegos que usas a diario guardan su corazón en una base de datos relacional. Cuando dudes, esta es tu apuesta segura.

Dicho esto, ninguna herramienta es perfecta para todo.

Donde las tablas empiezan a apretar

Hay datos que no se sienten cómodos dentro de una rejilla rígida. Tres ejemplos para que lo veas:

Datos que cambian de forma según el caso. Imagina la configuración de cada jugador de Kriaturas: uno guarda el idioma y el color del tablero; otro, además, diez ajustes de accesibilidad; un tercero, ninguno. Si quisieras meter eso en una tabla, tendrías una columna por cada ajuste posible, y la mayoría estarían vacías casi siempre. La rejilla, que tan bien funciona cuando todos los jugadores tienen los mismos datos, aquí se llena de huecos.

Relaciones enormes y entrelazadas. "Amigos de tus amigos de tus amigos." En tablas, eso son JOIN encadenados que se vuelven lentos y enrevesados a medida que la red crece. Cuando lo importante no son los datos sino la maraña de conexiones entre ellos, las tablas no son el terreno más natural.

Datos descomunales repartidos por todo el mundo. Cuando hablas de miles de millones de registros distribuidos en cientos de servidores por varios continentes, mantener todas las garantías estrictas de una base de datos relacional cuesta mucho. A veces conviene relajar algunas a cambio de velocidad y de poder crecer sin límite.

Reconocer estos límites no le quita ni un gramo de valor a lo relacional. Al contrario: es justo lo que te permite elegir bien la herramienta. Y para elegir, conviene saber qué hay en la caja.

Un paseo por las otras familias (NoSQL)

A todo este conjunto de bases de datos que no siguen el modelo de tablas se le suele llamar NoSQL. El nombre es un poco engañoso: no significa "sin SQL" ni "enemigas de SQL", sino "no solo relacionales". Son familias distintas, cada una pensada para un tipo de problema. Vamos a ver las cuatro más reconocibles, con una idea por cada una y un guiño a dónde encajaría en un juego como Kriaturas. No hace falta que te las aprendas: basta con que sepas que existen y para qué sirven.

Documentales

En vez de filas rígidas, guardan documentos flexibles: algo parecido a una ficha donde cada elemento puede tener los campos que necesite, sin obligar a que todos sean iguales. MongoDB es el ejemplo más conocido.

¿Dónde encajaría en Kriaturas? Justo en esa configuración variada de cada jugador del ejemplo de antes. Cada jugador guarda su ficha de ajustes con los campos que le hagan falta, y se acabaron las columnas vacías.

Clave-valor (a menudo, en memoria)

Las más simples y veloces. Guardan parejas clave → valor, como un diccionario gigante: le das una llave y te devuelve su contenido al instante. No entienden de relaciones ni de consultas complejas; lo suyo es ir rapidísimo. Redis es un referente.

¿Dónde encajaría? En el marcador en vivo de jugadores conectados o en las sesiones de quien está jugando ahora mismo: datos que cambian a cada segundo y que necesitas leer y escribir a toda velocidad, sin grandes ceremonias.

De grafos

Modelan los datos como una red: puntos (jugadores) unidos por líneas (amistades). Están hechas para moverse por esas conexiones con naturalidad, por muy enrevesadas que sean.

¿Dónde encajaría? En "amigos de tus amigos" y en las recomendaciones sociales: "jugadores parecidos a ti tienen estas cartas, ¿las quieres?". Lo que en tablas eran JOIN encadenados, aquí es pasear por la red.

Orientadas a columnas (analíticas)

Guardan los datos por columnas en lugar de por filas. Eso las hace muy buenas para el análisis masivo: cuando quieres calcular medias, totales y tendencias sobre millones de registros de golpe.

¿Dónde encajaría? En las estadísticas globales de Kriaturas: la duración media de las partidas del último año, la carta más usada entre cien millones de mazos, la evolución del juego mes a mes. Análisis a lo bestia.

La idea que une a todas

Fíjate en el patrón: cada familia es buena para un tipo de problema concreto. Ninguna es "mejor" en abstracto. La documental brilla con datos flexibles; la clave-valor, con la velocidad pura; la de grafos, con las redes de relaciones; la de columnas, con el análisis masivo. Y el modelo relacional sigue siendo el punto de partida y la opción por defecto para datos estructurados con relaciones e integridad: es decir, para la mayoría de las cosas.

Lo importante no es memorizar esta lista. Es haber entendido el problema lo bastante bien como para reconocer cuándo te has salido del terreno de las tablas y saber hacia dónde mirar. Y eso —fíjate— ya lo sabes hacer.

El cierre de verdad: tú y la IA

Toca rematar la idea que ha recorrido todo el libro, desde la primera página.

Es cierto, y cada vez más: la IA te genera el esquema de una base de datos en segundos. Le describes tu juego y te escupe las tablas, las claves y hasta las consultas. Los frameworks modernos (los ORM) crean las tablas solos a partir de las clases de tu programa. Es una ayuda enorme, y sería absurdo no aprovecharla.

Pero fíjate en lo que ha pasado a lo largo de estas páginas. Aprendiste a poner una clave foránea... y también a entender qué ocurre al borrar el jugador del que cuelgan los mazos. Aprendiste a normalizar... y a no pasarte de frenada quedándote en la tercera forma normal. Aprendiste a indexar... y a no indexarlo todo "por si acaso", porque cada índice se paga. Aprendiste a meter operaciones en una transacción... y a decidir cuáles van juntas y cuáles no.

Ninguna de esas decisiones la toma la herramienta por ti. La IA te da un punto de partida; qué hacer con él lo decides tú. ¿El esquema que te ha generado tiene sentido para cómo se juega de verdad a tu juego? ¿Ese índice que ha puesto sobra, o falta otro? ¿Esa tabla está bien normalizada, o va a darte problemas el día que crezca? ¿Estas dos operaciones tienen que ir en la misma transacción, sí o sí?

Para responder a todo eso necesitas exactamente lo que ahora tienes: los fundamentos. Y esa es la clave del asunto: la IA no hace que entender las bases sea menos importante, lo hace más. Cuanto más rápido se genera algo, más valioso es saber juzgar si está bien, depurarlo cuando falle y rediseñarlo cuando el juego crezca.

Quien entiende los cimientos manda sobre la herramienta. Quien no, depende de ella y se cree lo que le diga, para bien o para mal. Tú empezaste este libro sin saber qué era una tabla. Ahora sabes diseñar, proteger, consultar y acelerar la base de datos entera de un juego, y reconocer cuándo el problema pide otra cosa. Ese criterio —no la velocidad para teclear— es lo que te convierte en arquitecto.

Hasta aquí (y hasta donde tú quieras)

Cierra el libro un momento y piensa en el camino. Empezaste con una libreta desbordada y la pregunta "¿cómo guardo todo esto en orden?". Ahora tienes la respuesta entera en la cabeza: una entidad, una tabla; los datos en su sitio y una sola vez; reglas que se cumplen solas; operaciones que van todas o ninguna; consultas que sacan el ranking de la nada; índices que lo hacen volar. Y, cuando las tablas no basten, el criterio para mirar más allá.

Esto no es el final de nada. Es el principio. Tienes los cimientos para construir lo que quieras —el juego que sueñas, la app que tienes en mente, lo que se te ocurra— y, sobre todo, para no dejar que ninguna herramienta lo haga por ti sin que entiendas qué está haciendo.

Las bases ya las dominas. Ahora ve a construir.