Menos es más en cuanto a las bases de datos en Notion

Como parte de nuestro servicio de Notion Officer, donde nos quedamos en los espacios de nuestros clientes para brindar soporte mensual, hacemos limpiezas de bases de datos, revisiones del sistema y, en general, auditorías de buenas prácticas.

Aunque hacemos entrenamientos, workshops y compartimos guías de mejores prácticas, de vez en cuando nos encontramos con historias de terror 👻 como la siguiente.

El caso de las 12 bases de datos de eventos

Imagina esta escena:

Una página de “Eventos” con 12 bases de datos diferentes, una por cada mes del año, todas en la misma página. (A esto le sumamos que están realmente creadas en la sección “Private” de un usuario puntual, de ahí el No access).

‍

‍

Cuando vemos algo así, no lo tratamos solo como “caos que hay que ordenar”. Lo usamos como una oportunidad para reforzar conceptos clave y entender mejor por qué, en Notion, cuando hablamos de bases de datos, menos casi siempre es más.

Porque no se trata solo de estética o “orden visual”. Tener 12 bases de datos (una por mes) en lugar de una sola base bien diseñada tiene implicaciones técnicas, de mantenimiento y de escalabilidad para los equipos. Aunque Notion no “explote” ni nos marque errores, el sistema se vuelve más frágil y difícil de sostener.

Vamos por partes para explicar esto:

1. Rendimiento y carga de la página

Cada base de datos es un bloque por si solo, que tiene un peso dentro del sistema: tiene su propio esquema, sus propias vistas, sus acciones, sus filtros y su lógica.

• 12 bases de datos = 12 bloques o motores que Notion tiene que cargar y recalcular.
• En páginas con muchas bases de datos, la carga inicial es más lenta y el scroll se siente menos fluido, sobre todo en equipos más viejos o con conexiones lentas.

Con una sola base de datos bien diseñada, Notion puede reutilizar estructura y datos en varias vistas.

Con 12 bases que en el fondo representan lo mismo, el sistema trabaja de más, consumimos más recursos sin aportar ningún beneficio real.

2. Escalabilidad: cuando el sistema tiene que crecer o cambiar

Aquí es donde el “luego lo arreglamos” se vuelve una trampa. Cada vez que quieres hacer un cambio de estructura:

• Añadir un campo como Responsable, Tipo de evento o Estado.
• Ajustar opciones de un select o status.
• Modificar una fórmula o un filtro

Con una sola base, lo haces una vez. Con 12 bases, lo haces 12 veces.

Eso no solo es más trabajo: es campo minado para errores y para perder homogeneidad.

¿Qué podría pasar?

Actualizamos una base de datos pero las otras se quedan desfasadas, otras tienen opciones distintas… y poco a poco los datos dejan de ser comparables.

Este no era el caso de esta base de datos, pero, si además tenemos automatizaciones (internas de Notion o externas), el problema se multiplica y nos metemos en un problema de verdad: Cualquier lógica basada en triggers como “cuando se crea un evento” tiene que contemplar 12 orígenes distintos. Y si necesitas hacer cambios, de nuevo, los debes hacer 12 veces.

3. Análisis y reporting: el verdadero infierno

Cuando los datos están partidos en 12 bases distintas, ver el año completo deja de ser algo posible y se convierte en un malabar.

• Para responder algo tan simple como “¿cuántos eventos tuvimos este año?” tienes que mezclar información de 12 sitios diferentes.
• Preguntas como “¿cuántos eventos de cada tipo hicimos este trimestre?” exigen o bien una base agregadora extra o 12 filtros manuales y vistas duplicadas.

Con una sola base de eventos, en cambio:

• Filtras por fecha: este mes, últimos 90 días, este trimestre, etc.
• Agrupas por mes, tipo de evento, cliente, estado, el eje que quieras.
• Construyes dashboards que se alimentan siempre de la misma fuente maestra.

Cuando los datos están fragmentados:

• El filtro por fecha solo funciona dentro de cada base.
• No existe una vista global verdaderamente viva y que nos de información anual.
• Cualquier dashboard se convierte en una página con silos separados en lugar de un sistema limpio que pueda escalar a nivel de equipo y de tiempo—por ejemplo, para comparar un año con otro.

Si quieres solucionar este pain point, date una vuelta por nuestro curso de arquitectos.

‍4. Datos incoherentes con el paso del tiempo

Cuando el modelo está duplicado, la incoherencia no es una posibilidad—es un hecho. Solo es cuestión de tiempo antes de que el sistema se rompa.

Con el tiempo es habitual ver cosas como:

• Enero tiene Tipo de evento con opciones A, B, C.
• Abril tiene A, B, D.
• Septiembre tiene A, C, D y un misterioso “Pendiente revisar” o un “En pausa” que nadie sabe quién lo añadió.

El resultado: no puedes agrupar ni contar con confianza, porque cada mes habla un idioma ligeramente distinto.

5. El coste mental para el equipo

Más allá de lo técnico, nunca debemos olvidar el factor humano. Tener varias fuentes de información genera fricción y esta se traduce casi siempre en que: la gente se confunde, se cansa y simplemente deja de registrar la información porque no confía en ella. Y un sistema donde los datos no se registran bien es un sistema que pierde valor.

También es mucho más difícil de enseñar y documentar:

• Es mucho más simple decir:

“Tenemos una base de datos de Eventos. Siempre ahí. Filtramos por fecha.”

• Que explicar:

“Cada mes tiene su propia base. Aquí está enero, aquí febrero… y si quieres ver todo el año, te vas a este dashboard especial que mezcla varias cosas.”

6. ¿Y los límites de Notion? ¿No es mejor “partir” para que pese menos?

Las páginas de Notion soportan mucho más que 12 bases de datos. El problema no será “me voy a quedar sin memoria”. Lo que realmente afecta al rendimiento será la combinación de varios factores:

• Muchas bases de datos en la misma página.
• Muchas vistas complejas (filtros, grupos, fórmulas) activas a la vez.
• Si las vistas o bases de datos no tienen un límite de filas que mostrar cargará mucha información.

Por eso, a nivel de diseño de sistema, suele ser mejor: Una base de datos única, bien pensada y estructurada y con buenas vistas, que muchas bases pequeñas que representan lo mismo dividido artificialmente.

7. En conclusión: casi siempre es mejor una sola fuente de verdad

Cuando hablamos de bases de datos en Notion, menos será más.

Recuerda crear una sola base de datos de eventos, con:

• Propiedades claras.
• Vistas (pestañas) por mes, trimestre, tipo de evento, estado, cliente, equipo, etc.
• Filtros por fecha bien definidos.

Es más:

• Rápida de cargar.
• Fácil de mantener.
• Escalable cuando el sistema crece.
• Confiable a la hora de analizar y tomar decisiones.

Los sistemas que realmente escalan son los que tienen una única fuente de verdad para cada tipo de información. Todo lo demás son vistas, filtros y formas de mirar los mismos datos.

Y en Notion, eso casi siempre empieza por una decisión sencilla, pero potente:

Una base bien diseñada, en lugar de doce que cuentan la misma historia por separado. Esta es solo una de las muchas buenas prácticas que contamos en nuestros cursos de Notion.

El más recomendado a la fecha es nuestro bootcamp de arquitectos porque incluye sesiones en vivo y mentorías de Notion.

¡Hasta la próxima!