the association.3 In addition, since each row is a user, we would need to include the user’s other attributes, including the name, password, etc.

    The problem with the data model in Figure 11.6 is that it is terribly redundant: Each row contains not only each followed user’s id, but all their other information as well—all of which are already in the users table. Even worse, to model user followers we would need a separate, similarly redundant followers table. Finally, this data model is a maintainability nightmare: Each time a user changed (say) his name, we would need to update not just the user’s record in the users table but also every row containing that user in both the followed_users and followers tables.

      The problem here is that we are missing an underlying abstraction. One way to find the proper abstraction is to consider how we might implement the act of following

in a web application. Recall from Section 7.1.2 that the REST architecture involves resources that are created and destroyed. This leads us to ask two questions: When a user follows another user, what is being created? When a user unfollows another user, what is being destroyed?