Cómo pasar de Google Sheets a una base de datos de verdad

Todo negocio empieza con una hoja de cálculo. Clientes en Google Sheets. Pedidos en Google Sheets. Inventario en Google Sheets. Y funciona.

Funciona hasta el día en que tres personas escriben a la vez y alguien machaca la fila de otro. O hasta que necesitas que un cliente vea sus datos y solo los suyos. O hasta que tienes ocho pestañas que se referencian entre ellas con BUSCARV y una de las fórmulas se rompe sin que nadie sepa cuándo.

Ese día es el día de la mudanza. Y no pasa nada: la hoja hizo su trabajo. Pero no es una base de datos y nunca lo fue.

¿Cuándo toca dejar la hoja de cálculo?

No es una cuestión de tamaño. He visto hojas de 40.000 filas funcionando perfectamente y hojas de 300 filas que eran un infierno.

Toca mudarse cuando aparece cualquiera de estas cinco señales:

Relaciones. Tienes una pestaña de clientes y otra de pedidos, y cada pedido pertenece a un cliente. Si estás resolviendo eso con BUSCARV, estás simulando una relación a mano. Una base de datos hace eso de forma nativa y no se rompe.

Varias personas a la vez. Google Sheets tiene edición colaborativa, sí, pero no tiene permisos por fila ni control de quién puede tocar qué campo. Cualquiera con el enlace puede cargarse una columna entera.

Validación real. En una hoja, si alguien escribe "Madird" en vez de "Madrid", la hoja se lo traga. En una base de datos defines que ese campo es una lista cerrada y no hay forma de meter basura.

Vistas distintas para gente distinta. Comercial quiere ver sus clientes. Administración quiere ver las facturas. En una hoja eso son copias, y las copias se desincronizan siempre.

Necesitas una app encima. El momento en que dices "estaría bien que esto tuviera un formulario para el móvil" es el momento en que la hoja ya no da más de sí.

Si no te pasa ninguna de las cinco, no te muevas. La mejor base de datos es la que no necesitas montar.

¿Qué es "una base de datos de verdad" para alguien que no programa?

No estoy hablando de montar PostgreSQL en un servidor. Estoy hablando de las herramientas que la gente llama "bases de datos sin código": tienen aspecto de hoja de cálculo pero por dentro funcionan como una base de datos relacional.

Las dos que uso y recomiendo son Airtable y SmartSuite.

Airtable es la conocida. Interfaz muy pulida, curva de aprendizaje suave, y un plan gratuito que aguanta un proyecto pequeño. Su problema es el precio en cuanto creces: pasa de gratis a caro bastante rápido y los límites de registros por base se te echan encima.

SmartSuite es menos famosa y a mí me gusta más para negocio. Trae los procesos de trabajo incorporados (tareas, estados, automatizaciones) sin tener que montarlos a mano, y el precio por usuario aguanta mejor cuando sois un equipo pequeño. Si vas a mover un negocio entero ahí dentro y no solo una tabla, mírala.

Lo que tienen las dos y no tiene una hoja: campos con tipo real (fecha es fecha, no texto que parece fecha), enlaces entre tablas, vistas filtradas, permisos, formularios nativos y una API para conectar cosas.

Esto lo he desarrollado más en el mapa general de bases de datos y CRM sin código, que es donde comparo el panorama completo.

Paso 1: dibuja las tablas antes de tocar nada

Este es el paso que todo el mundo se salta y el que decide si la mudanza sale bien.

Coge un papel. Escribe las entidades de tu negocio: las cosas que existen. Clientes. Pedidos. Productos. Proveedores. Cada entidad va a ser una tabla.

Ahora dibuja las flechas: un cliente tiene muchos pedidos. Un pedido tiene muchos productos. Un producto tiene un proveedor.

Si tu hoja actual tiene una pestaña gigante donde en la misma fila está el cliente, el pedido y el producto, ahí tienes el problema: eso son tres tablas metidas en una. Y por eso se repite el nombre del cliente 400 veces y cuando cambia su teléfono hay que cambiarlo en 400 sitios.

Regla práctica: si un dato se repite idéntico en muchas filas, ese dato quiere ser su propia tabla.

Paso 2: crea las tablas vacías y define los tipos

En Airtable o SmartSuite, creas una base nueva y dentro una tabla por entidad. Todavía sin datos.

Para cada columna, elige el tipo correcto. Esto es aburrido y es lo que hace que la base funcione:

• Texto corto para nombres.
• Email para emails (te valida el formato solo).
• Teléfono para teléfonos.
• Fecha para fechas, con el formato europeo puesto desde el principio.
• Selección única para estados (Pendiente, Pagado, Enviado). Nunca texto libre.
• Número con decimales para importes, y ojo con el separador.
• Enlace a otra tabla para las relaciones.

Ese último es el importante. En la tabla Pedidos creas un campo de tipo enlace que apunte a la tabla Clientes. A partir de ahí, cada pedido lleva su cliente de verdad, no una copia de su nombre.

Paso 3: exporta, limpia e importa

De Google Sheets, Archivo, Descargar, CSV. Una pestaña por archivo.

Antes de importar nada, limpia. Y aquí no me alargo porque lo tengo contado entero en cómo importar datos sin cargarte la base, pero el resumen es: revisa tildes, revisa el formato de fecha, elimina duplicados y quita las filas de totales que Sheets tiene al final de la hoja.

Luego importas. Primero las tablas "padre" (Clientes, Productos), y después las "hijas" (Pedidos), porque los enlaces necesitan que el otro registro ya exista.

Al importar Pedidos, el campo de enlace se rellena buscando por nombre exacto. Si en la hoja el cliente se llama "Talleres Gómez" y en la tabla Clientes está como "Talleres Gomez SL", no lo va a encontrar y te va a crear un cliente nuevo duplicado. Por eso la limpieza previa importa tanto.

Lo que se te va a atascar

Las fórmulas no vienen. Todo lo que tenías con BUSCARV, SUMAR.SI o ÍNDICE hay que rehacerlo con campos calculados o de lookup. La buena noticia: la mayoría desaparecen, porque lo que hacía la fórmula ahora lo hace la relación.

El histórico. Si tu hoja tenía columnas del tipo "Enero, Febrero, Marzo" con un número en cada una, eso en una base de datos es una tabla aparte con una fila por mes. Duele al principio y luego lo agradeces.

La gente. Tu equipo lleva dos años escribiendo en la hoja y la nueva herramienta les parece rara. Déjales una vista que se parezca lo máximo posible a lo que tenían y no les enseñes las 400 opciones el primer día.

No borres la hoja. Déjala en solo lectura durante un mes. Vas a necesitar consultarla más veces de las que crees.

¿Y ahora qué?

Cuando la base esté montada, lo que se abre es todo lo demás: formularios para que la gente meta datos sin tocar la base, automatizaciones que te avisan cuando algo cambia, y aplicaciones encima para el móvil.

Todo eso es imposible sobre una hoja de cálculo y es de lo más fácil que hay sobre una base de datos. La mudanza es el trabajo duro. Lo que viene después es donde se nota.

Si te interesa el contexto de por qué la hoja se te quedó pequeña y qué señales lo anunciaban, lo conté con un caso concreto en la hoja de cálculo que se nos quedó pequeña.

Algunos enlaces de este artículo son de afiliado: si contratas la herramienta, me llevo una comisión sin que a ti te cueste más.

Si no tienes claro por dónde empezar a meter la IA y las herramientas en tu forma de trabajar, tengo un test rápido que te dice en qué punto estás y qué te conviene montar primero.

Hacer el test de IA