El caso: una cafetería que quiere vender en línea
Doña Martha tiene una cafetería en Zapopan. Hoy toma pedidos por WhatsApp en una libreta y ya perdió dos semanas de datos cuando se le mojó. Quiere una app sencilla donde el cliente vea el menú, haga pedidos y ella registre qué se vendió y a quién.
Tu trabajo no es programar: es diseñar la base de datos y entregar una especificación clara para que una IA la construya bien. Esto es exactamente lo que hace un buen vibe coder.
Paso a paso guiado
Ruta del proyecto
Levanta las entidades
¿Qué cosas distintas hay que guardar? Para la cafetería: cliente, producto (del menú) y pedido. Cada una será una tabla. Si te sale una tabla que mezcla dos cosas, sepárala.Define campos con tipo
Para cada tabla, lista sus campos y su tipo. producto: nombre (texto), precio (número). cliente: nombre (texto), telefono (texto). pedido: fecha (fecha), total (número), cliente_id (número).Conecta con claves
Todo pedido pertenece a un cliente: agrega cliente_id como foránea en pedidos. Un pedido puede incluir muchos productos y un producto aparece en muchos pedidos: eso es muchos a muchos y pide una tabla puente pedido_producto.Escribe tres consultas clave
Pide en español lo que Doña Martha necesita ver: los pedidos de hoy, el producto más vendido, los clientes de Zapopan. Redacta qué tabla, qué filtro y qué columnas llevaría cada una.Cierra con respaldo y seguridad
Decide la frecuencia de respaldo (por ejemplo, diario automático), que siempre respaldarás antes de migrar, y que toda consulta usará parámetros para evitar el SQL injection.
Paso 1 de 5
Un borrador para critiquear
Un compañero propuso guardar todo en una sola tabla 'pedidos' con columnas: cliente_nombre, cliente_telefono, producto_nombre, producto_precio, cantidad, fecha. Vamos a juzgar esa decisión con lo que aprendiste.
Contra la tabla única
Argumenta por qué una sola tabla que mezcla cliente, producto y pedido es un mal diseño para la cafetería.
Tesis
Guardar todo junto duplica información y vuelve frágil el sistema.
Evidencia
El teléfono del cliente se repite en cada uno de sus pedidos.
Razonamiento
Si cambia el precio de un producto, se pierde el precio real de las ventas pasadas.
Conclusión
El diseño separado con claves es la base de un sistema que no colapsa.
Contraargumento
Alguien dirá que una sola tabla es más simple de escribir al inicio.
Tu respuesta al contraargumento
Esa simplicidad se paga caro al crecer: separar con foráneas escala y conserva la historia.
Doña Martha crece y en seis meses tendrá 40,000 pedidos. Si deja la tabla única mal diseñada, ¿qué problema es más probable al consultar "los 10 productos más vendidos"?
¿Qué tan seguro te sientes de entregar el diseño de base de datos de tu propio producto siguiendo estos pasos?
¿Qué tan seguro estás de tu respuesta?
Escribe tu entrega del proyecto para TU producto (no el de la cafetería): lista tus tablas con dos o tres campos cada una y su tipo, indica las relaciones, y anota tu regla de respaldo y tu regla de seguridad.
Formato sugerido: tabla → campos (tipo); luego "clientes 1—N pedidos"; luego tres consultas; luego respaldo diario y consultas parametrizadas.
Tu texto se guarda sólo en este dispositivo.
Una base de datos bien diseñada no se nota; una mal diseñada se nota todos los días.
— Regla de campo para vibe coders
Cerraste el curso de Bases de datos
Aquí se mira lo que ya fuiste acertando. Pulsa «Comprobar» para saber si puedes seguir.
Fin del Curso 12 y del Nivel 1 (Entender). Sigues la ruta hacia el Nivel 2 (Construir), empezando por Agentes de IA desde cero: tu software deja de esperar clics y empieza a actuar solo.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.