In the elaboration phase of our first iteration, we came up with a database model for our system.
Most of the model is relatively straightforward, but we would like to elaborate on a couple of design decisions we made in order to make this database model work well.
1.) The escalation policy outlined here can hold one of two things: a group of users to notify or a group of devices to notify. The difference here is based on what object is holding it, whether it is a group or a user. These could have been broken into two different documents, and most likely would have been if we had been using a relational database. However, since we’re using MongoDB, a document storage database, it makes more sense to abstract out this document, and allow for both types of policies to be held in one place.
2.) The second design decision we made also had to do with escalation policies, but in this case it had to do with the list of subscribers. With subscribers, order matters, because it changes how they will be notified and when. The order is also something that needs to be easy to change, since the users can change their device order at any point, and the groups will most likely be rotating their user order at least once a month. There were two options that we discussed: putting an order field on each subscriber or using the order of the list itself as it’s already defined. We discussed the merits of both ideas, and decided that we should use the order of the list as it’s saved in the database as the way of storing order. This way, we can just replace the list in the database with a new list when the order changes, rather than running through each user/device in the list to update the order.