| ¿Por qué desestimaste crear los campos FechaInicial (o Fecha_de_entrada), y FechaFinal (o Fecha_de_salida), para tener controlados los periodos de alquiler de los apartamentos?.
¿Qué pasará cuando cambies de año?. Si tienes una tabla de meses y otra de días, ¿Cómo sabrás si estamos hablando del 10 de julio de 2007, del 10 de julio de 2008, o del 10 de julio de 1876?.
En la tabla inmo, que sería la que contiene la descripción de cada apartamento, pondría un nuevo campo: localidad, por si la inmobiliaria tiene apartamentos a disposición de la gente, en distintas localidades (si tu inmobiliaria solo alquila en "Villarriba", pues incluyes también ese campo, así puedes vender esa aplicación a más clientes, con menos "trastornos").
Como supongo que cada apartamento tendrá un precio diferente, en esa misma tabla también incluiría tres campos más, que serían los precios en temporada alta, media y baja (precio/día). En otra tabla llamada temporadas incluiría los periodos en los que se inicia cada temporada.
Ejemplo:
temporadaalta: 20/05 (a partir del 20 de mayo de cualquier año).
temporadamedia: 10/10 (a partir del 10 de octubre de cualquier año).
temporadabaja: 08/01 (a partir del 8 de enero de cualquier año).
Crearía también una tabla llamada alquileres (borraría la de meses y dias), con los campos siguientes:
id_apto: id del apartamento que se alquila.
fechainicial: fecha en la que empieza a computar el periodo de alquiler (1er día de alquiler), es decir, en la que se entra al apartamento.
fechafinal: fecha del último día de alquiler (este día también computa como periodo de alquiler). Al día siguiente, antes de las 12:00 del mediodía (o cuando estipule la empresa inmobiliaria), se debe dejar libre el apartamento.
[EDITADO]
Edito el post, porque pensando, incluiría otro campo que sería el precio total del alquiler durante ese periodo inicial y final, que aunque no es imprescindible, pues se puede obtener al vuelo, es preferible tenerlo grabado por si cambian las tarifas a posteriori, pues si queremos obtener el importe total "al vuelo" (precio/día según temporada x número de días), sin estar grabado en un campo de la BD, como el nuevo precio habría subido (se supone que los precios suben), los cálculos estarían inflados, y no serían reales.
No sé si me he explicado... (es lunes, y todavía estoy "sobao").
[/EDITADO]
Con esas 3 tablas y con esos campos, podemos saber entre otras cosas:
Qué apartamento está alquilado, qué día se entra y que día se sale, el precio que tiene, si el apto. se alquila en temporada alta, media, baja, o incluso, si una parte de los días está alquilado en alta, otro en medio, u otro en baja. Por exclusión se podrá saber el primer día en el que estará disponible para su alquiler (el día siguiente de fechafinal). También podremos saber qué apartamentos están libres a día de hoy (20 de noviembre de 2006), buscando que la fecha de hoy no estuviese dentro del rango "fechainicial", y "fechafinal".
Puede que lo que te he dicho no sea lo mejor, por eso antes de hacer nada, lo ideal es que cojas un papel y lápiz, y empieces a apuntar posibles contingencias del tipo: ¿incluyo un mapa escaneado, con la ubicación del apartamento para facilitar el acceso al mismo al usuario que desea alquilarlo, y por tanto añado un campo a la tabla inmo, con la ruta de la imagen del mapa? (puestos a facilitar las cosas, yo lo incluiría, ...todo sea por "vender" o en este caso "alquilar"), y similares. De esa forma, también analizarás mentalmente el proceso de alquiler de un apartamento desde el punto de vista del cliente (el usuario que desea alquilar el apto.), y te darás cuenta de si necesitas tal o cual información para añadir a la BD.
Esta es una opinión de amateur, ya que no soy programador.
Suerte con ese trabajo.
A ver que opinan los gurús del foro...
Última edición por 3pies; 20/11/2006 a las 05:40 |