jordi fita mas
7eb718dfd9
This is actually only used for plots, but, of course, it means that every booking now can potentially have many booked campsites, and have to create a relation for it. I now have a conundrum regarding stay dates: i need them to be in the same table as the campsite_id, because constraints only work on a single relation and without the dates i can not make sure that i am not overbooking a given campsite; but, on the other hand, all campsites under the same booking must be for the same dates. Where does stay belong, then? In booking or booking_campsite? If in booking then i can not have a constraint that most assuredly will bite me in the back, but if in booking_campsite then each campsite could potentially have different dates. As far as i can see, i can not use a exclude constraint with <> for dates in booking_campsite to ensure that all rows with the same booking_id have the same stay (i.e., exclude those that have a different stay for the same booking_id). For now, the say is in **both** relations: in booking, because i need it when it is a prebooking, at least, and in booking_campsite for the aforementioned constraint requirements. Will this come back and bite me? Yes, it will. But what can i do?