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 clustering column. Which is better?

The answer largely depends on how closely coupled the related data types are. If we expect that most of our interactions with user profile information will also involve interacting 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 accommodate several different one-to-many relationships where the user plays the role of parent. It's not clear that the relationship between users and status updates is more fundamental 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.