Database Reference
In-Depth Information
The difference is simply the interface to the data model: are we working with one table, or
two? It turns out that
users_with_status_updates
behaves very much like the
result of an SQL
LEFT JOIN
of
users
and
user_status_updates
. Cassandra, of
course, does not support JOIN clauses when reading data; instead, this join is baked into
the schema itself through the use of static columns.
When to use static columns
We've now seen two ways to model users, each of whom has many status updates. The
first approach was simply to define a table for users, and a table for their status updates;
the relationship between the two is encoded in the key structure of
user_status_updates
. The second approach is to store all of the information in one
users_with_status_updates
table using static columns to associate user-level
data with the
username
partition key rather than having a different value for each clus-
tering column. Which is better?
The answer largely depends on how closely coupled the related data types are. If we ex-
pect that most of our interactions with user profile information will also involve interact-
ing with the user's status updates, and vice versa, then it makes a lot of sense to store them
together in one table. The reasoning is similar to the parent-child conceptual framework
discussed earlier, but in reverse. Not only is the user a "special" relationship from the
standpoint of the status update, but also the status update is a special relationship from the
standpoint of the user.
In the case of MyStatus, on balance, the relationship between users and status updates
doesn't quite pass this test. In subsequent chapters, we'll expand our schema to accom-
modate several different one-to-many relationships where the user plays the role of "par-
ent". It's not clear that the relationship between users and status updates is more funda-
mental than the other relationships that we will model for users.
For this reason, we'll continue to work with the
users
and
user_status_updates
tables, and leave behind the
users_with_status_updates
table as an interesting
exercise.
