Bases de datos para diseñadores: tablas, filas y permisos

¿Cómo se organiza una tabla?

Piensa en una hoja de cálculo con reglas estrictas. Cada columna tiene un nombre y un tipo, y cada fila guarda un conjunto de valores, uno por columna. El tutorial oficial de PostgreSQL muestra una tabla de clima con las columnas city, temp_lo, temp_hi, prcp y date, y un tipo para cada una: texto de hasta 80 caracteres, enteros, números con decimales y fechas (PostgreSQL, tutorial de tablas).

Los tipos importan porque limitan el error. Una columna numérica no acepta la palabra “ocho”, y una columna de fecha rechaza un texto que no sea una fecha válida. Si una app guarda precios como texto, no puede sumarlos ni ordenarlos bien.

Cada tipo de dato se ve en la interfaz. Una fecha pide un selector de fecha, un estado con tres valores posibles pide un menú o un grupo de opciones, y un campo de texto libre pide validación. Cuando el diseño y la tabla no coinciden, el error aparece como un formulario que acepta cualquier cosa.

¿Qué es una clave primaria?

Es una columna, o un conjunto de columnas, cuyo valor identifica cada fila de forma única. Sin ella, dos registros idénticos son indistinguibles, y cambiar uno puede afectar al otro sin que nadie lo note. La guía de tablas de Supabase recomienda crear una clave primaria para cada tabla, y su editor de tablas genera por defecto las columnas id y created_at (Supabase, Tables).

Para un diseñador, la clave primaria responde a una pregunta práctica: ¿cómo se refiere la interfaz a un registro concreto? Si el botón “Editar” de una lista no sabe qué fila editar, la clave está mal definida.

¿Quién puede ver cada fila?

Esta es la parte que más se olvida con apps generadas por IA. Cuando una app habla con la base directamente desde el navegador, usa una clave pensada para ser pública. Supabase la llama clave publicable. Eso es normal; lo que protege los datos son las reglas de la base, no la clave.

Según la documentación de Supabase, una tabla del esquema public es alcanzable por su API. Si la seguridad a nivel de fila (RLS, Row Level Security) no está activada, la propia documentación advierte que cualquiera con la clave publicable puede leer y escribir todas las filas (Supabase, Tables). Si está activada pero no hay ninguna regla, las peticiones no devuelven filas hasta que exista una política. Una política funciona como un filtro que se aplica a cada consulta: por ejemplo, “solo las filas cuyo user_id sea el de la persona que pregunta” (Supabase, Row Level Security).

Dos detalles prácticos de esa documentación:

• El editor de tablas del panel de Supabase activa RLS al crear una tabla; las tablas creadas con SQL no la activan, y hay que hacerlo a mano. Una herramienta de IA que genera las tablas con SQL puede dejarlas abiertas.
• La clave secreta se salta las reglas y la documentación indica no usarla nunca en el navegador. Es la razón de que existan los secretos y las variables de entorno.

Esto explica por qué una app generada puede verse bien en la demo y exponer datos reales: quien la prueba entra con su propia cuenta y ve sus datos. Que otra persona vea esos mismos datos solo se descubre probando con una segunda cuenta.

¿Qué cambia si la herramienta usa Firebase?

Algunos generadores de apps usan Firebase en lugar de Supabase. Cloud Firestore, una de las bases de datos de Firebase, no usa tablas: según su documentación, es una base de datos de documentos NoSQL. Los datos van en documentos (registros con campos, parecidos a JSON) y los documentos viven dentro de colecciones. Además no tiene esquema fijo, así que dos documentos de la misma colección pueden tener campos distintos (Firebase, modelo de datos de Firestore).

Para el diseñador, la pregunta no cambia: ¿quién puede leer o escribir cada dato? En Firestore la respuesta son las reglas de seguridad, que se evalúan en cada petición de un cliente web o móvil. La documentación muestra un ejemplo de reglas que permite todo y advierte que nunca debe usarse en producción, porque permite a cualquiera sobrescribir toda la base (Firebase, reglas de seguridad de Firestore). Como no hay un esquema fijo, conviene que el equipo acuerde los campos de cada colección para que las pantallas no se rompan.

¿Qué decisiones de datos le tocan al diseño?

Un diseñador no escribe las tablas, pero sí decide qué datos hacen falta y cómo se muestran. Cuatro preguntas ayudan a definir una tabla antes de pedirla:

1. ¿Qué es una fila? (una cita, un cliente, un pedido)
2. ¿Qué datos mínimos tiene cada fila y de qué tipo son?
3. ¿Qué identifica una fila de forma única?
4. ¿Quién puede ver cada fila, y quién puede cambiarla?

Si no sabes responder la cuarta, la tabla no está lista para producción.

Ejemplo

Ejemplo ilustrativo: un estudio de diseño necesita un registro de solicitudes de clientes. La diseñadora responde las cuatro preguntas: una fila es una solicitud; tiene nombre del cliente, fecha, tipo de proyecto y estado (una lista cerrada de tres valores); la clave es un id generado; y cada cliente solo puede ver sus propias solicitudes, mientras el equipo interno ve todas. Cuando pide la tabla a la IA, comprueba que las reglas de acceso estén activas. Con dos cuentas de prueba, confirma que un cliente no ve las solicitudes de otro. Esa prueba rápida separa un prototipo de un sistema con datos reales.

¿Cómo aplicarlo mañana?

1. Antes de pedir una tabla, escribe las cuatro preguntas anteriores con una respuesta por cada una. Si falta alguna, la tabla todavía no se pide.
2. Pide a la IA que muestre la definición de la tabla con sus tipos de dato. Revisa que las fechas sean fechas y que los estados sean una lista cerrada de valores, no texto libre.
3. Pregunta si la seguridad a nivel de fila (o las reglas de seguridad, si usa Firebase) está activada en cada tabla o colección, y qué política tiene.
4. Crea dos cuentas de prueba y confirma que cada una ve solo sus filas, antes de mostrar la pantalla a nadie.
5. Anota qué datos personales guarda cada tabla y para qué. Si no encuentras una razón de diseño, no los guardes.

Para ver cómo se publica una app con sus datos, lee deploy para diseñadores. Y para el recorrido completo de una app generada, de idea a app en un día.

Errores comunes

• Guardar fechas o números como texto.
• Crear tablas sin clave primaria o sin una forma de identificar cada fila.
• Olvidar las reglas de acceso porque la demo funciona.
• Probar solo con una cuenta, la del propietario de la base.
• Dejar activas unas reglas que permiten todo “mientras se prueba”.
• Guardar datos personales “por si acaso” sin una razón de diseño.
• Pensar que la interfaz oculta una columna y, por tanto, la protege: si la base la entrega, quien consulta la API la ve.

Fuentes

• PostgreSQL, “Creating a New Table” (tablas, columnas y tipos de datos): https://www.postgresql.org/docs/current/tutorial-table.html
• Supabase, “Tables and data” (columnas por defecto, clave primaria y RLS en tablas nuevas): https://supabase.com/docs/guides/database/tables
• Supabase, “Row Level Security” (políticas, claves publicable y secreta): https://supabase.com/docs/guides/database/postgres/row-level-security
• Firebase, “Cloud Firestore data model” (documentos, colecciones, sin esquema fijo): https://firebase.google.com/docs/firestore/data-model
• Firebase, “Get started with Cloud Firestore Security Rules”: https://firebase.google.com/docs/firestore/security/get-started