Eu tenho um banco de dados de design para um sistema de reservas. Os requisitos do sistema de reservas são os seguintes:
- O sistema de reservas permite ao usuário reservar um horário (1 hora) entre 8h e 13h de segunda a sexta-feira.
- O usuário pode reservar um local para esse intervalo de tempo de 1 hora.
- O sistema de reservas está aberto por 13 semanas, depois descansa por 13 semanas e abre por mais 13 semanas e descansa por 13 semanas a cada ano.
O problema que enfrento ao projetar a tabela é que existem 3 variáveis de controle importantes - intervalo de tempo, local e 13 semanas.
Eu esbocei o design tendo uma tabela que contém uma quantidade fixa de linhas. (Assim, para 8h às 13h, haverá 5 slots e, portanto, cada semana terá 25 slots. Suponha que haja 3 locais, então terei 25 slots x 3 locais, o que me dá 75 linhas. Então eu multiplique 75 por 26 semanas, porque há duas 13 semanas que o sistema estará aberto. Assim, isso me dará 1950 linhas fixas.
Mas, o problema será que se eu aumentar o número de horas terminando às 22h, terei 14 slots por dia, o que significa que cada semana terá 70 slots. E se o local aumentar para 10 locais, terei 70 slots x 10 locais, o que me dá 700 linhas. Claro, multiplique por 26 semanas, precisarei ter uma tabela que contenha 18.200 linhas fixas. O design será difícil de gerenciar, pois há muitas linhas.
A tabela ficaria mais ou menos assim:
+------------------------------------------------- ---------------------+ | Identificação | Semana | Tempo | Local | Usuário | Estado | +------------------------------------------------- ---------------------+ | 000001 | 1 | 8h | Sala 1 | | Disponível | | 000002 | 1 | 9h | Sala 1 | | Disponível | | 000003 | 1 | 10h | Sala 1 | | Disponível | | | | 018200 | 26 | 22h | Sala 10 | | Reservado | +------------------------------------------------- ---------------------+
O ID será o PK para esta tabela.
Existe uma maneira de acompanhar cada slot de reserva, mas sem criar uma quantidade fixa de linhas para cada slot de reserva? (Cada slot de reserva conterá 3 dados importantes - a semana, hora, local)
Se a preocupação for a manutenção manual de um grande número de linhas, você pode resolver isso (possivelmente) criando tabelas para cada uma de suas dimensões: semanas, intervalos de tempo e locais. O conjunto completo de slots possíveis para reserva seria o produto cruzado dessas três dimensões. As reservas reais seriam outra tabela com chaves estrangeiras apontando para todas essas três tabelas de dimensão.
Com esse tipo de design, em vez de manter 3 x 25 x 26 registros, você manterá 3 + 25 + 26 registros. Observe que se você separar o dia da semana e a hora do dia em duas tabelas, poderá reduzir ainda mais o número de registros a serem mantidos (3 + 5 + 5 + 26).
O problema com essa abordagem é quando (e se) você tem uma exceção. Este projeto assume que não há blecautes em sua programação. Por exemplo, e se você fechar um quarto por algumas semanas para ser reformado? Uma maneira de lidar com esse problema é criar registros de reservas que cubram os apagões. Se você tiver exceções suficientes, gerenciá-las pode ser quase tão ruim quanto usar apenas o método de força bruta.
A questão que eu consideraria seriamente é se gerar ou não a lista inicial de slots disponíveis para reserva é realmente um grande negócio. Você pode facilmente automatizar o processo para gerar sua grande pilha de slots disponíveis. Esta é realmente apenas uma única consulta.
A maneira mais simples é armazenar apenas as reservas reais no banco de dados.
A tabela que você forneceu pode ser usada se você mudar
WeekparaDate. O campo de status pode ter mais de um valor, comoBooked,Not Available, etc.Se você consultar o banco de dados para ambos
DateeTimenenhum registro for retornado, isso significa que a sala está disponível. As reservas canceladas podem ser implementadas excluindo registros ou marcando o campo de status comoCancellede eliminando esses registros da consulta de disponibilidade.Usei um esquema semelhante em um sistema de reserva de táxi.