Bases de datos explicadas simple (para gente de marketing)

Si trabajás en marketing y la palabra "base de datos" te suena a territorio de programadores, este tutorial es para vos. Al terminar vas a entender qué es una base de datos de verdad, en qué se diferencia de tu planilla de siempre, y vas a poder hablar con una IA (o con un dev) sobre tus datos sin sentirte turista. No hace falta instalar nada ni saber programar.

Antes de empezar

• Ninguna herramienta obligatoria. Con leer alcanza, aunque tener a mano un chat de IA (Claude, ChatGPT, el que uses) ayuda para probar los ejemplos.
• Alguna planilla tuya real: clientes, leads, ventas, contenido. Los conceptos entran mejor con datos que conocés.
• Quince minutos sin interrupciones.

Paso 1 — Entendé qué es una tabla (spoiler: ya usás una)

Una base de datos guarda información en tablas, y una tabla se parece muchísimo a una hoja de cálculo: filas y columnas. Cada fila es un registro (un cliente, una venta, un lead) y cada columna es un dato de ese registro (nombre, teléfono, fecha).

La diferencia clave no es la forma, es la disciplina. En una planilla podés escribir cualquier cosa en cualquier celda: un teléfono donde va un precio, "consultar" donde va un número. En una base de datos cada columna tiene un tipo definido —texto, número, fecha— y si intentás meter algo que no corresponde, el sistema te lo rechaza. Esa "rigidez" es justo lo que después te salva.

Paso 2 — Conocé al ID: la cédula de identidad de cada fila

En una base de datos bien armada, cada fila tiene un identificador único que no se repite jamás: el ID (también le dicen clave primaria). Puede ser un número que sube solo (1, 2, 3...) o un código raro de letras y números.

¿Para qué sirve? Pensá en dos clientes que se llaman "María González". En tu planilla, cuando filtrás por nombre, las mezclás. Con un ID, cada María es inconfundible aunque compartan nombre y ciudad. Todo lo demás puede cambiar; el ID nunca.

Paso 3 — Las relaciones: por qué no todo va en una sola tabla

Acá está el salto mental más importante. En una planilla, si un cliente te compra cinco veces, o repetís sus datos en cinco filas o hacés cinco columnas ("compra 1", "compra 2"...). Las dos opciones envejecen mal.

Una base de datos lo resuelve con dos tablas relacionadas:

• Tabla clientes: una fila por persona, con su ID.
• Tabla ventas: una fila por venta, y una columna que dice el ID del cliente que compró.

El cliente vive una sola vez en un solo lugar. Si cambia de teléfono, lo corregís en una fila y listo: todas sus ventas siguen apuntando a él. A esto se le llama relación, y es la razón por la que estas bases se llaman "relacionales".

Paso 4 — SQL: el idioma para hacerle preguntas a tus datos

SQL es el lenguaje con el que se le habla a la mayoría de las bases de datos, y se lee casi como inglés. Esta consulta:

SELECT nombre, telefono
FROM clientes
WHERE ciudad = 'Santa Cruz';

dice literalmente: "seleccioná nombre y teléfono, de la tabla clientes, donde la ciudad sea Santa Cruz".

La buena noticia de esta época: no necesitás aprender SQL de memoria. Le describís a una IA lo que querés en español —"dame los clientes que compraron más de dos veces este año"— y te devuelve la consulta lista. Tu trabajo es entender lo suficiente para leer lo que te dio y detectar si pidió otra cosa.

Paso 5 — Traducí tu planilla a este mundo (ejercicio de 5 minutos)

Agarrá tu planilla real y contestá esto, con ayuda de la IA si querés:

1. ¿Qué "cosas" distintas conviven ahí? (clientes, ventas, campañas...) Cada cosa pediría su propia tabla.
2. ¿Qué dato se repite en muchas filas? Eso es señal de que falta una tabla aparte con relación.
3. ¿Cada fila tiene algo que la identifique sin ambigüedad? Si no, ahí iría un ID.

Pegale a la IA los encabezados de tu planilla (los encabezados, no los datos de tus clientes) y pedile: "¿cómo dividirías esto en tablas relacionadas y qué ID usarías?". Vas a ver tu propio caos ordenado, y eso enseña más que cualquier teoría.

Errores comunes

• Creer que "base de datos" = algo enorme y caro. Hay bases de datos que son un simple archivo en tu compu (SQLite, por ejemplo, gratis). El tamaño no define nada; las reglas sí.
• Usar el nombre o el teléfono como identificador. Los nombres se repiten y los teléfonos cambian. Arreglo: ID propio que no signifique nada y no cambie nunca.
• Meter todo en una sola tabla gigante. Si repetís los mismos datos en muchas filas, tarde o temprano quedan versiones contradictorias. Arreglo: una tabla por "cosa", conectadas por ID.
• Pedirle SQL a la IA sin entender la respuesta. Si no podés leer la consulta, no podés saber si pregunta lo que vos querías. Arreglo: pedile siempre "explicame línea por línea qué hace".

Siguiente paso

Con los conceptos claros, lo natural es ensuciarse las manos: crear una base chiquita con tus propios datos y hacerle preguntas reales. Y cuando ya tengas datos viviendo en una base —o heredés la de un cliente—, el siguiente nivel es auditarla: encontrar duplicados, campos vacíos y formatos rotos con ayuda de la IA. Ese es exactamente el tutorial que sigue a este.