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

The structure of the status updates table

The most notable aspect of user_status_updates is that it has two columns for a primary key. This means that each row is identified uniquely by the combination of its username and id columns. It also means that every row must have a value in both of these columns.

In addition to this, our user_status_updates table is the first time we've seen a timeuuid column in the wild. As you can recollect from the previous chapter, a UUID is essentially a very large number that is generated using an algorithm that guarantees that the identifier is unique across time and space.

You will also recollect that Cassandra does not have the ability to generate auto-incrementing sequences for use in primary keys as this would require an unacceptably high level of coordination between nodes in the cluster. In the users table, we used a natural key; we want each user to have a unique username, so the username column makes a perfectly good unique identifier for rows.

In the case of a status update, however, there is no obvious natural key. The only user-generated data associated with a status update is the body, but a free text field doesn't make a very good primary key, and anyway, there's no guarantee that status update bodies will be unique. This is where UUIDs come in handy. Since they're guaranteed to be unique, we can use them as a surrogate key—a unique identifier that isn't derived from the data in the row. Auto-incrementing primary keys in relational databases are also surrogate keys.

主站蜘蛛池模板: 醴陵市| 皋兰县| 三门县| 桃园市| 都匀市| 汉川市| 桦南县| 华宁县| 庐江县| 彰化县| 丁青县| 徐汇区| 渝北区| 安图县| 江华| 明星| 舞阳县| 天津市| 井研县| 贵溪市| 西充县| 嘉黎县| 苏尼特右旗| 库车县| 兴安盟| 乐昌市| 泸水县| 红河县| 盐亭县| 江孜县| 阳山县| 乌鲁木齐县| 萍乡市| 黄平县| 六枝特区| 丘北县| 英德市| 永嘉县| 博客| 湟源县| 会同县|