Del aula al almacén de la empresa: conexión, esquemas y permisos

Has escrito cientos de consultas contra tablas que cabían en tu portatil. Has cargado ficheros CSV de tres mil filas, has creado vistas, has jugado con ventanas y CTEs. Y entonces llega el lunes de tu primer empleo, te pasan unas credenciales por un chat interno y te dicen: "conéctate al almacén, el esquema de analítica se llama analytics_prod". Te sientas delante del cliente SQL, pegas la cadena de conexión, le das a conectar... y aparecen doscientas tablas con nombres que no entiendes, en un motor que no es DuckDB, con permisos que no te dejan hacer la mitad de lo que hacías ayer en tu entorno de prácticas. Todo lo que sabías sigue siendo válido. Pero el terreno ha cambiado.

Esta lección no va de aprender SQL nuevo. Va de lo que cambia cuando el SQL que ya sabes se ejecuta contra un almacén de datos real, con millones de filas, permisos estrictos, tablas sin documentar y convenciones de nombres que nadie te ha explicado. Es la diferencia entre aprender a conducir en un circuito cerrado y salir a la carretera un viernes por la tarde: el volante es el mismo, los pedales son los mismos, pero el contexto no tiene nada que ver.

### Lo que cambia de tu entorno de prácticas al almacén real

En tu laboratorio de DuckDB tenías el control absoluto. Podías crear tablas, borrarlas, cambiar columnas, cargar datos a tu antojo. Eras propietario de todo porque tú mismo lo habías construido. El almacén corporativo es exactamente lo contrario: alguien lo construyó antes de que llegaras, lo mantiene un equipo que no conoces todavía, y tu papel es consumir los datos que otros producen. Esa asimetría no es un castigo ni una señal de desconfianza: es el diseño correcto. Un almacén de datos que cualquiera pudiera modificar sin control se rompería en una semana.

• ▹Volumen: de miles de filas a cientos de millones. Una consulta que en DuckDB tardaba 0,1 segundos puede tardar treinta en un almacen remoto si no la escribes con cuidado. SELECT * FROM pedidos ya no es una exploración inocente: puede mover gigas de datos por la red.
• ▹Permisos: solo lectura. No puedes crear tablas en el esquema de producción, ni borrar nada, ni modificar una columna. Si necesitas una tabla intermedia, te dan un espacio aparte (un sandbox o esquema personal) donde sí puedes escribir.
• ▹Latencia: el almacen está en la nube, no en tu disco duro. Cada consulta viaja por internet, se encola, se ejecuta y vuelve. Ese tiempo muerto no existía en local.
• ▹Tablas sin documentar: nadie te ha dejado un README al lado de cada tabla explicando qué significa cada columna. Hay doscientas tablas y muchas tienen nombres internos como stg_orders_v2 o dim_customer_legacy que no se explican solos.
• ▹Convenciones de nombres: cada empresa tiene las suyas. Unas usan prefijos (fct_ para hechos, dim_ para dimensiones, stg_ para staging), otras no. Unas ponen la fecha en el nombre de la tabla, otras en una columna. Hasta que las aprendes, leer el catálogo es como leer en un idioma que medio entiendes.
• ▹Datos reales: ya no son datos inventados de ejemplo. Son datos de clientes de verdad, con sus implicaciones legales y éticas. No se copian a tu portatil sin permiso, no se enseñan en una captura de pantalla y no se mandan por email.

### Conectarte por primera vez: la cadena de conexión

La primera vez que te conectas a un almacén corporativo, alguien del equipo de datos o de infraestructura te da lo que se llama una cadena de conexión (connection string): una línea de texto que contiene la dirección del servidor, el puerto, el nombre de la base de datos, tu usuario y, a veces, la contraseña (aunque cada vez más empresas usan autenticación por SSO, es decir, el mismo usuario y contraseña que usas para entrar en el correo corporativo). Esa cadena se pega en el cliente SQL que uses: puede ser DBeaver, DataGrip, el propio terminal de psql o cualquier otro. Una vez conectado, ves el catálogo de esquemas y tablas, como si abrieras el explorador de ficheros de un ordenador ajeno.

1-- Ejemplo de cadena de conexion (Redshift)
2-- host: analytics-cluster.abc123.eu-west-1.redshift.amazonaws.com
3-- port: 5439
4-- database: warehouse
5-- user: ana.garcia (tu usuario corporativo)
6-- schema por defecto: analytics_prod
7
8-- Una vez conectado, lo primero que haces:
9SELECT current_user;        -- quien soy
10SELECT current_database();  -- donde estoy
11SELECT current_schema();    -- en que esquema caigo por defecto

### Esquemas: las carpetas del almacén

Si una base de datos es un edificio, los esquemas son las plantas. Cada planta tiene sus propias salas (tablas) y sus propios inquilinos (roles con acceso). Cuando trabajabas en DuckDB local, todo vivía en un único esquema llamado main, así que nunca te hacía falta pensar en ello. En un almacén corporativo hay muchos esquemas, cada uno con un propósito distinto, y saber en cuál estás y a cuáles tienes acceso es lo primero que necesitas para no perderte.

El patrón más habitual que te vas a encontrar es este: un esquema raw o landing donde aterrizan los datos tal cual llegan del origen (la aplicación, el CRM, el proveedor externo), un esquema staging o intermediate donde los ingenieros los transforman y limpian, un esquema de producción analítica (analytics, dwh, o similar) donde viven las tablas ya preparadas para consultar, y un esquema personal o sandbox donde tú puedes crear tablas temporales sin molestar a nadie. Solo tienes acceso de lectura al esquema de producción y acceso completo a tu sandbox. A raw y staging, normalmente, ni los ves.

1-- Listar los esquemas a los que tienes acceso
2-- (la sintaxis varia segun el motor; esto es PostgreSQL/Redshift)
3SELECT schema_name
4FROM information_schema.schemata
5ORDER BY schema_name;
6
7-- Listar las tablas de un esquema concreto
8SELECT table_name
9FROM information_schema.tables
10WHERE table_schema = 'analytics_prod'
11ORDER BY table_name;
12
13-- Ver las columnas de una tabla
14SELECT column_name, data_type
15FROM information_schema.columns
16WHERE table_schema = 'analytics_prod'
17  AND table_name = 'fct_orders'
18ORDER BY ordinal_position;

### El rol de solo lectura: por qué no te dejan escribir

Cuando ves que tu rol solo permite SELECT y no puedes hacer un CREATE TABLE ni un INSERT, la primera reacción es sentirlo como una limitación molesta. En DuckDB podías materializar una CTE como tabla temporal con un simple CREATE TABLE AS SELECT y reutilizarla en la siguiente consulta. Ahora no puedes. Pero ese límite no es un capricho del equipo de infraestructura: es una decisión de diseño que protege a la empresa y, sin que lo notes, también a ti.

El almacén de producción alimenta dashboards, informes automáticos, procesos de facturación y modelos de machine learning. Si cualquier persona con acceso pudiera escribir en él, un error de dedo (un UPDATE sin WHERE, un DROP TABLE accidental) podría dejar sin datos a toda la empresa durante horas. Además, escribir en producción rompe la trazabilidad: nadie sabría quién modificó qué dato y cuándo, lo que convierte cualquier auditoría en una pesadilla. El rol de solo lectura no significa que no confíen en ti; significa que el sistema está diseñado para que un error humano no pueda causar una catástrofe.

¿Y si lo que has hecho en tu sandbox tiene que quedarse? Pasa antes de lo que crees: escribes una consulta para un informe puntual, gusta, y a los dos meses tres personas dependen de ella. Ahí tu tabla del sandbox deja de servir, porque es tuya, es temporal y nadie la mantiene si te vas de vacaciones. Lo que toca entonces no es pedir permiso de escritura en producción: es pedir que tu consulta se convierta en una tabla del almacén, mantenida por el equipo de datos como todas las demás. Y la forma de pedirlo es llevarla ya escrita, probada en tu sandbox y con el número que produce comprobado contra algo conocido. Un ingeniero que recibe eso lo pone en producción en una tarde; uno que recibe «necesito una tabla de retención» tarda dos semanas en entender qué le estás pidiendo.

### Tablas sin documentar: cómo orientarse sin mapa

En un mundo ideal, cada tabla del almacén tiene un diccionario de datos (un documento que explica qué significa cada columna, cuándo se actualiza y de dónde viene). En la realidad, ese diccionario existe en la mitad de las empresas y está actualizado en un cuarto de ellas. Lo más probable es que tu primer día encuentres doscientas tablas con nombres crípticos, ningún README visible y una documentación que tiene seis meses de retraso. No es que la empresa sea un desastre: es que documentar cuesta tiempo y el tiempo siempre pierde contra "sacar este informe para mañana".

Cuando no hay documentación, tu único recurso es la exploración metódica. No abras tablas al azar rezando para encontrar la correcta: usa un sistema. Primero, entiende el patrón de nombres. Los prefijos más comunes te cuentan el linaje del dato sin necesidad de abrirlo:

• ▹fct_ o fact_ — tabla de hechos: eventos que ocurrieron (pedidos, clics, pagos). Suelen tener muchas filas y pocas columnas descriptivas.
• ▹dim_ — tabla de dimensiones: entidades estables (clientes, productos, tiendas). Suelen tener pocas filas y muchas columnas descriptivas.
• ▹stg_ — staging: versión intermedia, a medio limpiar. Normalmente no la consultas directamente.
• ▹raw_ o src_ — datos en crudo del origen. Tampoco sueles consultarla salvo que no haya otra opción.
• ▹agg_ o rpt_ — tabla ya agregada o preparada para un informe. Puede ser exactamente lo que buscas, o puede tener un nivel de detalle que no te sirve.
• ▹tmp_ o test_ — tabla temporal de alguien. No confíes en ella: puede desaparecer mañana.

### Qué preguntar el primer día (y a quién)

Hay un puñado de preguntas que, si las haces el primer día, te ahorran semanas de tanteo a ciegas. No son preguntas técnicas complicadas: son las que nadie se acuerda de contarte porque para ellos ya son obvias. No tengas vergüenza de hacerlas. Todo el mundo que lleva tiempo en la empresa las responde en treinta segundos, y ninguna de ellas se puede averiguar solo mirando el catálogo de tablas:

1. 01.¿Cuál es el esquema principal donde consulto las tablas curadas? (Evita que pierdas una hora buscando en staging.)
2. 02.¿Tengo un sandbox? ¿Cómo se llama? (Necesitas saberlo antes de tu primera CTE materializada.)
3. 03.¿A qué hora se actualizan los datos? (Si la carga nocturna termina a las 7:00, una consulta a las 6:50 puede darte los datos de ayer por la mañana, no los de anoche.)
4. 04.¿Hay algún diccionario de datos o documentación de las tablas principales? (Aunque sea un Google Doc a medias, es mejor que nada.)
5. 05.¿Cuál es la tabla de hechos principal del negocio? (Cada empresa tiene una tabla estrella: fct_orders, fct_transactions, fct_events. Es donde empiezas casi todo.)
6. 06.¿Hay algo que no deba hacer? (Consultas muy pesadas en horario pico, tablas sensibles que requieren aprobación especial, datos de clientes que no se pueden exportar.)
7. 07.¿Quién es la persona que más sabe de este almacén? (Para cuando te atasques de verdad, saber a quién preguntar vale más que cualquier documento.)

### Latencia y coste: tu consulta ya no es gratis

En DuckDB, cada consulta se ejecutaba en milisegundos y no costaba nada: la electricidad de tu portatil. En un almacén en la nube, cada consulta tiene un coste real medido en dinero, y ese coste crece con la cantidad de datos que escanea. En BigQuery, por ejemplo, pagas literalmente por cada terabyte escaneado; en Redshift o Snowflake el modelo es distinto pero la idea de fondo es la misma: los recursos del almacén son compartidos y finitos. Una consulta que escanea una tabla entera de mil millones de filas sin ningún filtro puede tardar minutos y consumir recursos que otros necesitan al mismo tiempo.

Esto no significa que tengas que vivir con miedo a ejecutar consultas. Significa que el hábito del LIMIT, del filtro por fecha y de no pedir columnas que no necesitas —el famoso SELECT * del que ya hablamos— cobra una importancia nueva. En tu laboratorio era un atajo inofensivo para explorar. En producción es una forma de escanear cien columnas cuando solo necesitabas tres, y de multiplicar por treinta el coste y el tiempo de tu consulta sin ningún beneficio.

### Tu primera semana: una hoja de ruta

Los primeros días en un almacén nuevo se parecen mucho a mudarte a una ciudad que no conoces. Puedes andar sin rumbo esperando encontrar algo útil, o puedes seguir un plan mínimo que te oriente. Este plan no es oficial en ninguna empresa, pero funciona en todas:

1. 01.Dia 1: Conectarte, ejecutar las tres consultas de orientacion (usuario, base, esquema), listar los esquemas disponibles y anotar cuales son los tuyos.
2. 02.Dia 2: Explorar el esquema de producción analitica: contar tablas, leer los prefijos, identificar las 5-10 tablas que se usan mas (pregunta a un compañero cuales son).
3. 03.Dia 3: Elegir la tabla de hechos principal y hacerle un reconocimiento: columnas, tipos de datos, un COUNT(*), un LIMIT 10, y el rango de fechas que cubre.
4. 04.Dia 4: Reproducir alguna cifra que ya conozcas (el numero de pedidos del mes pasado que sale en un dashboard existente) para comprobar que tu consulta da lo mismo.
5. 05.Dia 5: Documentar lo que has aprendido en un fichero personal. Nadie te lo va a pedir, pero dentro de un mes te lo vas a agradecer a ti mismo.

### Reproducir una cifra conocida: tu prueba de fuego

El paso más importante de esa primera semana, y el que más gente se salta, es reproducir un número que ya existe en algún sitio: el total de ventas del mes pasado que aparece en un dashboard, el número de usuarios activos que alguien mencionó en una reunión, la cifra de retención que sale en el informe mensual. Si tu consulta da exactamente el mismo número, sabes que estás consultando la tabla correcta con los filtros correctos. Si no da lo mismo, has descubierto algo valioso antes de que nadie te pida un análisis nuevo: o estás mirando la tabla equivocada, o hay una diferencia de criterio que necesitas entender.

Este ejercicio de reproducción no es solo para novatos. Los analistas con experiencia lo hacen cada vez que trabajan con una tabla nueva o con un almacén que no conocían: antes de construir nada encima, comprueban que el cimiento da los números esperados. Si el cimiento no cuadra, todo lo que construyas encima estará torcido sin que lo notes hasta que alguien te pregunte de dónde sale tu cifra y te des cuenta de que el suelo se mueve debajo.