Database Reference
In-Depth Information
Chapter 5. Establishing Relationships
At this point, we might declare our MyStatus application a minimum viable product. Users
can create accounts and post status updates, and those status updates can be viewed in their
authors' timelines. And, of course, since we're storing the data in Cassandra, we don't need
to worry about scaling up to millions of users or billions of status updates.
As our service grows, however, it would be nice for users to be able to view all their
friends' status updates in one place. The first step of that, of course, would be to know who
a user's friends are. So, we'll build a feature that allows one user to follow another.
We've already seen a good way to use Cassandra to model a specific type of relationship.
Compound primary keys are a natural fit for parent-child associations but a follow relation-
ship is many-to-many: I follow many users, and—hopefully—many users follow me.
In this chapter, we'll build on our knowledge of Cassandra data modeling and introduce
new patterns to model relationships. We'll explore two ways to model relationships. First,
we will explicitly create a table whose role is to represent the relationship between two oth-
er entities. Second, we'll look at how secondary indexes can help us represent relationships
without the need for an extra lookup table.
By the end, we'll have two alternative data structures to capture followers in the database,
and you'll have learned:
• How to model many-to-many relationships in Cassandra
• How query-driven design can produce denormalized data structures
• How to delete rows from a Cassandra table
• How to create secondary indexes
• The limitations and disadvantages of secondary indexes
