In the case of the festival App we didn't have a full specification provided in advance to work from. Given that, I assumed some flexibility in the final design was acceptable but normally would not do that without discussing my proposed changes or enhancements with the project steering committee!
In every development project there will always be a trade-off between time to deliver, cost to build and functionality needed. Also, I like to make the final user interface as simple as possible, which usually means more complexity for the developer but I feel that trade-off is almost always justified.
I think your logic agrees with mine in that I wanted to avoid asking a user to figure out the correct date each time they added a band or updated the status in the Set Times table. Some people suggested using date range restrictions, pick lists, etc. but I didn't see any final solutions that I thought were complete so decided to take a different approach.
I decided to split the Set Times object DATE/TIME info into two fields. (Day and Hour) I also didn't worry about using an actual date field (I used a text field) as I didn't anticipate needing any date calculations associated with these records although a full date value (ddd mm/dd/yyyy) could be entered in that field in the future if someone decided having the date values would be useful.
In the end I decided to go with a fully populated Set Times table with all of the days and set times filled in. The only updates a user can make are for adding the band name and changing the status. Creating the records was pretty easy, one record for each combination of stage, day, time slot ... lots of copy/paste in Excel to build the master table and then import it into the Salesforce Set Times object.
The Status field is a picklist.
For the relationship between Set Times and Band Objects I used a Lookup, not Master-Detail. This allows more flexibility when assigning Bands to different time slots and was a requirement in order to add new records without band names during the import process.
Populating the Set Times table with all of the available time slots at once enables development of other planning tools like a dashboard gauge that shows percentage of time slots filled vs still open, and views or reports showing actual remaining time slots, by date, time and stage.
My Set Times object view looks like this.
