Question

I was looking for a database model for a simple agenda application but I could not find any. StackOverflow has plenty of questions regarding this matter, but none of them offer a concrete answer. So I researched further and came up with a model of my own, which I am presenting to you so that you can help me evaluate and improve it. And may this serve as a reference for people looking for this in the future.

This model is inspired by the functionality provided by Outlook, although it was heavily cut down. It is intended to be supported by a considerable amount of application code.

CREATE TABLE dbo.Users (
    UserId UNIQUEIDENTIFIER NOT NULL,
    CONSTRAINT PK_Users PRIMARY KEY (UserId))

CREATE TABLE dbo.Appointments (
    -- Keys.
    AppointmentId INT IDENTITY NOT NULL,
    ParentAppointmentId INT NULL,
    UserId UNIQUEIDENTIFIER NOT NULL,
    -- General fields.
    EventDescription VARCHAR(500) NULL,
    EventName VARCHAR(50) NOT NULL,
    -- Schedule fields.
    IsCancelled BIT NOT NULL, /* To cancel only one appointment in a series of recurring appointments. */
    AppointmentDate DATE NOT NULL,
    IsAllDayEvent BIT NOT NULL,
    StartTime TIME NULL, /* This field is required in case IsAllDayEvent = false */
    DurationInMinutes INT NULL, /* This field is required in case IsAllDayEvent = false */
    RecurrenceCount SMALLINT NULL,
    RecurrenceEndDate DATE NULL,
    RecurrenceType TINYINT NULL, /* 1 = Daily, 2 = Weekly (other recurrence types are not supported by design) */
    WeeklyRecurrenceDays VARCHAR(13), /* 1,2,3,4,5,6,7 (each number represents a day of the week, where 1 = sunday) */
    -- Constraints.
    CONSTRAINT PK_Appointments PRIMARY KEY (AppointmentId),
    CONSTRAINT PK_Appointments_Appointments FOREIGN KEY (ParentAppointmentId) REFERENCES dbo.Appointments(AppointmentId),
    CONSTRAINT FK_Appointments_Users FOREIGN KEY (UserId) REFERENCES dbo.Users(UserId))

Highlights:

• The appointment end-time can be obtained by adding the value of DurationInMinutes to StartTime.
• An appointment can last for a whole day, when IsAllDayEvent = 1. In that case, the fields StartTime and DurationInMinutes are not required.
• Recurrence features are to be calculated by the application code. Even if the appointment is recurrent, it is registered in the database only once, and the application is responsible for calculating the dates when the appointment is to be repeated and then show those dates in a calendar. To help the application perform better, the application can do the math for the period that is visible in the calendar only. Further performance can be achieved by caching these calculations somewhere, evicting them when the user changes the recurrence settings or deletes the appointment.
• The number of times a recurrent appointment is repeated is determined by looking at the RecurrenceCount or RecurrenceEndDate fields. Only one of them should contain a value at a time.
• This model supports editing one or more appointments in a series. That’s what the ParentAppointmentId is for. Suppose there’s a recurrent appointment called “Example appointment”, configured to recur every day for 5 times. Then suppose the user chooses to edit only the third appointment of the series, changing its name to “Updated appointment”. This would cause the application to duplicate the original appointment record in the database, but using the new name, and making it reference the original appointment (parent). It would be the responsibility of the application to detected that there’s an appointment with different properties in the series and take that into account when it is calculating the recurrences to show in the calendar, as I mentioned before.
• Still about the ParentAppointmentId feature: the user is able to cancel one or more appointments in a series. E.g. “I want this event to happen on all thursdays, but not on that specific thursday”. This would again make the duplication process as above, but setting the child appointment IsCancelled field to 1 (true). The application should then “hide” this specific appointment when showing the series in a calendar.
• Still about the ParentAppointmentId feature: to simplify application logic, and following the Outlook model, when the user changes the recurrence settings for the original appointment, which causes the entire series to be recalculated, child appointments are lost.

---

Well, I think this is it. Please tell me if you agree with this approach, or in case you don’t, what would you change, if not taking a completely different approach.

Thanks in advance.

Answer 1

I’m not sure that you are doing anything terrible here…

one thought would be to break out the parentAppointmentId completely and construct a new associative table that simply links two arbitrary appointements. you would then probably put on some role or type column to identify what type of relation was being defined.

in this way, you gain flexibility of allowing much more comlex associations in the series (such as skipping – renaming etc) as well as allowing for the possibility that one appointment may be the result or followon to possibly many other appointments – not just one.

when just thinking of normalization – the recurrence information is strictly not part of the appointment itself either. perhaps consider pulling recurrence info to a new table and associating only to the relevant appointments.