Na verdade, trabalhei na concepção e implementação de um sistema de reservas de hotéis e posso oferecer os seguintes conselhos com base na minha experiência.
Eu recomendaria sua segunda opção de design, armazenando um registro para cada combinação individual de data/hotel. A razão é que, embora haja períodos em que a tarifa de um hotel seja a mesma em vários dias, é mais provável que, dependendo da disponibilidade, mudará com o tempo e se tornará diferente (os hotéis tendem a aumentar a tarifa do quarto à medida que a disponibilidade diminui).
Além disso, há outras informações importantes que precisarão ser armazenadas e específicas para um determinado dia:
- Você precisará gerenciar a disponibilidade do hotel, ou seja, na data x existem s quartos disponíveis. Isso quase certamente variará de acordo com o dia.
- Alguns hotéis têm períodos de blecaute em que o hotel fica indisponível por curtos períodos de tempo (normalmente dias específicos).
- Tempo de espera - alguns hotéis só permitem que os quartos sejam reservados com um certo número de dias de antecedência, isso pode variar entre os dias da semana e os fins de semana.
- Mínimo de noites, novamente dados armazenados por data individual que diz que se você chegar neste dia, deverá ficar x número de noites (digamos, em um fim de semana)
Considere também uma pessoa reservando uma estadia de uma semana, a consulta do banco de dados para retornar as tarifas e disponibilidade para cada dia dessa estadia é muito mais concisa se você tiver um registro de preços para cada data. Você pode simplesmente fazer uma consulta onde a Data da Tarifa do Quarto está ENTRE a Data de Chegada e a Data de Partida para retornar um conjunto de dados com um registro por data da estadia.
Percebo que com essa abordagem você armazenará mais registros, mas com tabelas bem indexadas o desempenho será bom e o gerenciamento dos dados será muito mais simples. A julgar pelo seu comentário, você está falando apenas na região de 18.000 registros, que é um volume bem pequeno (o sistema em que trabalhei tem vários milhões e funciona bem).
Para ilustrar o gerenciamento de dados extra se você NÃO armazenar um registro por dia, imagine que um Hotel tenha uma tarifa de 100 USD e 20 quartos disponíveis para todo o mês de dezembro:
Você começará com um registro:
1-Dec to 31st Dec Rate 100 Availability 20 Então você vende um quarto no dia 10 de dezembro.
Sua lógica de negócios agora precisa criar três registros a partir do acima:
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 Em seguida, a taxa muda nos dias 3 e 25 de dezembro para 110
Sua lógica de negócios agora precisa dividir os dados novamente:
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 Isso é mais lógica de negócios e mais sobrecarga do que armazenar um registro por data.
Posso garantir que, quando você terminar, seu sistema terminará com uma linha por data de qualquer maneira, então você também pode projetá-lo dessa maneira desde o início e obter os benefícios de um gerenciamento de dados mais fácil e consultas de banco de dados mais rápidas.
