CODEWITHSUNDEEP
model
loddn
loddn

Reputation: 658

Booking calendar model design

I'm developing a availability calendar. The bookable events could have 1 or more resources available for booking and the events can be recurring and have some basic features like editing one instance of a recurring event etc (like Google Calendar for example). The calendar should also be able to store the bookings.

Example: Every Monday at 10:00, until the end of 2014 Unit A have 2 resources available, but not on Monday the 24/6. Last Monday UserX and UserY was booked on that Event, UserX didn't show up.

I have looked at a few design patterns for recurring events but can't really find a good and elegant way to handle both recurring events and attaching details to an individual event.

I have done some modelling bellow where I store the event and the recurrence in Event, then I have to create a EventDetails-instance for every individual event. 

class Event {

    Date start
    Date end

    boolean isRecurring
    EventRecurType recurType // DAILY, WEEKLY ...
    Integer recurInterval = 1
    Date recurEnd
    Integer recurCount
    List<EventDetails> eventDetails // Id, start, end, BookingDetails et.c.
}

I'm sure there's a better way to do this, can you please help me?

Upvotes: 2

Views: 642

Answers (1)

Zach Leighton
Zach Leighton

Reputation: 1941

Typically with database design you want to separate out the components and relate them on different keys. I'm assuming you know the basics regarding that.

So my initial thought would be:

Events, a table with event details - and an eid (Event id)

Users, a table with user details - and an uid (User id)

Recurring, a table with recurring events, keying on the eid and uid, with other relevant information such as the recurrence pattern (I'd use enums).

You don't want to put everything in one giant table as it will make for headaches, separation of concerns allows you to scale later.

Your lookups will be simple joins, and put indexes on fields that will be used to lookup data such as the date and user so that searches are faster, but don't go crazy because it makes inserts slow.

Hopefully this helps.

Upvotes: 1

Related Questions