¿Está bien mi modelo de datos para un sistema de reservas de vuelos?

Minimalism

Estoy diseñando una base de datos para un sistema de reservas de vuelos y me gustaría que revisaran mi lógica. Tengo las siguientes tablas:

VUELO (id, origen, destino, fecha_salida, fecha_llegada, capacidad)
PASAJERO (id, nombre, email)
RESERVA (id, id_vuelo, id_pasajero, fecha_reserva, estado)

Mi duda es: ¿debería tener una tabla separada para ASIENTO? Porque un pasajero puede reservar varios asientos en un mismo vuelo. Actualmente solo almaceno la cantidad de pasajeros en la reserva, pero creo que pierdo granularidad. ¿Qué opinan?

Podcasts

Creo que sí necesitas una tabla ASIENTO. De lo contrario, no podrías controlar qué asientos están ocupados ni reasignarlos. Algo como:

ASIENTO (id, id_vuelo, numero, clase, ocupado)

Y luego RESERVA_ASIENTO (id_reserva, id_asiento). Así también podrías manejar cambios de asiento fácilmente.

Minimalism

Buen punto. Pero, ¿no sería demasiado complejo? Si solo reservo por cantidad, con un campo 'num_asientos' en RESERVA bastaría. Pero entiendo que para control de ocupación individual es mejor tener la tabla. Gracias por el aporte.

Chess

Además del asiento, deberías considerar la normalización. Tu tabla VUELO tiene origen y destino como texto, pero sería mejor tener una tabla AEROPUERTO aparte y referenciar por ID. Así evitas redundancia y facilitas búsquedas.

BoardGames

Estoy de acuerdo con lo de aeropuerto. También añadiría una tabla CLASE_VUELO (turista, ejecutiva) si tu sistema maneja diferentes precios. Y en la relación RESERVA_ASIENTO podrías incluir precio pagado para mantener histórico.

Minimalism

Excelentes sugerencias. Voy a rediseñar incluyendo AEROPUERTO, ASIENTO y CLASE_VUELO. Me preocupa la performance con tantas tablas, pero supongo que con índices adecuados funcionará. ¡Gracias a todos!

Pottery

No te preocupes por la performance si indexas bien las claves foráneas. Además, para consultas de disponibilidad puedes usar vistas materializadas. Otra cosa: el campo 'estado' en RESERVA debería tener valores como 'confirmada', 'cancelada', 'check-in', etc. Quizás usar un ENUM.

Calligraphy

Buen punto lo del ENUM para estado, pero cuidado con los cambios futuros; yo prefiero una tabla ESTADO_RESERVA aparte para flexibilidad. Y sobre la performance, no solo índices: si esperas mucha concurrencia, mira el aislamiento de transacciones y bloqueos. ¿Has considerado usar un campo version para control de concurrencia optimista en la asignación de asientos?