Sí, me quedaría con eso, excepto que no eliminaría el registro cuando venza el alquiler. Sabrás fácilmente que un alquiler venció porque está en el pasado, por lo que también conservas automáticamente el historial de alquiler.
Después de todo, hay una cantidad infinita de fechas disponibles, por lo que tendría que limitar artificialmente el rango de fechas admitidas si hiciera lo contrario (y almacenara fechas libres).
En el futuro. Y, en cierto sentido, también en el pasado.
Además, supongo que desea información adicional en caso de que se alquile un servicio (por ejemplo, el nombre del arrendatario) y no habría ningún lugar para almacenar eso si el alquiler estuviera representado por una fila inexistente.
Dado que la granularidad del alquiler es un día completo, creo que está viendo una estructura de base de datos similar a esta:
Tenga en cuenta cómo RENTING_DAY PK evita superposiciones de forma natural.
Alternativamente, puede deshacerse de RENTING_DAY y tener START_DATE y END_DATE directamente en RENTING, pero esto requeriría una superposición de rango explícita de cheques , que puede no escalar idealmente .
