De hecho, he trabajado en el diseño e implementación de un sistema de reserva de hotel y puedo ofrecer los siguientes consejos basados en mi experiencia.
Recomendaría su segunda opción de diseño, almacenando un registro para cada combinación individual de Fecha/Hotel. El motivo es que, aunque habrá períodos en los que la tarifa de un hotel sea la misma en varios días, es más probable que, dependiendo de la disponibilidad, cambiará con el tiempo y se volverá diferente (los hoteles tienden a aumentar la tarifa de la habitación a medida que disminuye la disponibilidad).
También hay otra información importante que deberá almacenarse y que es específica para un día determinado:
- Deberá administrar la disponibilidad del hotel, es decir, en la fecha x hay y habitaciones disponibles. Es casi seguro que esto variará según el día.
- Algunos hoteles tienen periodos de bloqueo en los que el hotel no está disponible durante períodos breves (por lo general, días específicos).
- Tiempo de entrega:algunos hoteles solo permiten que las habitaciones se reserven con una cierta cantidad de días de anticipación, esto puede diferir entre los días de semana y los fines de semana.
- Mínimo de noches, nuevamente datos almacenados por fecha individual que dice que si llegas en este día debes quedarte x número de noches (digamos durante un fin de semana)
Considere también a una persona que reserva una estadía de una semana, la consulta de la base de datos para devolver las tarifas y la disponibilidad para cada día de esa estadía es mucho más concisa si tiene un registro de precios para cada fecha. Simplemente puede hacer una consulta en la que la Fecha de la tarifa de la habitación esté ENTRE la Fecha de llegada y la Fecha de salida para devolver un conjunto de datos con un registro por fecha de estadía.
Me doy cuenta de que con este enfoque almacenará más registros, pero con tablas bien indexadas, el rendimiento estará bien y la administración de los datos será mucho más simple. A juzgar por su comentario, solo está hablando en la región de 18000 registros, que es un volumen bastante pequeño (el sistema en el que trabajé tiene varios millones y funciona bien).
Para ilustrar la administración de datos adicionales si NO almacene un registro por día, imagine que un Hotel tiene una tarifa de 100 USD y 20 habitaciones disponibles para todo diciembre:
Comenzará con un registro:
1-Dec to 31st Dec Rate 100 Availability 20
Luego vendes una habitación el 10 de diciembre.
Su lógica empresarial ahora tiene que crear tres registros a partir del anterior:
1-Dec to 9th Dec Rate 100 Availability 20
10-Dec to 10th Dec Rate 100 Availability 19
11-Dec to 31st Dec Rate 100 Availability 20
Luego, la tasa cambia el 3 y el 25 de diciembre a 110
Su lógica comercial ahora tiene que dividir los datos nuevamente:
1-Dec to 2-Dec Rate 100 Availability 20
3-Dec to 3-Dec Rate 110 Availability 20
4-Dec to 9-Dec Rate 100 Availability 20
10-Dec to 10-Dec Rate 100 Availability 19
11-Dec to 24-Dec Rate 100 Availability 20
25-Dec to 25-Dec Rate 110 Availability 20
26-Dec to 31-Dec Rate 100 Availability 20
Eso es más lógica comercial y más gastos generales que almacenar un registro por fecha.
Puedo garantizarle que para cuando haya terminado, su sistema terminará con una fila por fecha de todos modos, por lo que también podría diseñarlo de esa manera desde el principio y obtener los beneficios de una administración de datos más fácil y consultas de base de datos más rápidas.
