官术网_书友最值得收藏!

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.

主站蜘蛛池模板: 昌乐县| 诸城市| 尚义县| 大连市| 长岭县| 巴里| 吉首市| 莱西市| 湾仔区| 邵阳县| 汽车| 益阳市| 玛曲县| 龙海市| 宜君县| 陆河县| 凤山市| 宝应县| 宁陵县| 湄潭县| 房产| 全南县| 绥中县| 合川市| 共和县| 台湾省| 金塔县| 焉耆| 光泽县| 保康县| 芦溪县| 安义县| 遂川县| 吉安县| 天祝| 隆昌县| 高青县| 德钦县| 辉南县| 英超| 枣阳市|