Modeling user notification preferences

In the previous section’s examples, we relied on the User model to answer one of the core notification system questions: should a user be notified via channel X or not? I intentionally used the most straightforward implementation: storing notification preferences in the users table as Boolean columns (notifications_enabled, email_notifications_enabled, and so on). Let’s discuss the downsides of this approach.

First, we add another responsibility to the User model (it likely already has many). That takes us one step closer to creating a God object—a famous maintainability killer (see the Seeking God objects section in Chapter 2, Active Models and Records).

Second, adding a new column for every new notification type widens the database table. Although it’s doubtful that you’ll hit the limit on the number of columns (PostgreSQL, for example, allows up to 1,600 columns per table), many columns add to mental...