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

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.

主站蜘蛛池模板: 龙川县| 安仁县| 岑溪市| 抚宁县| 新竹市| 铜川市| 隆昌县| 武义县| 山阴县| 体育| 酒泉市| 怀集县| 黑龙江省| 祥云县| 漳平市| 武山县| 磐安县| 钟山县| 建水县| 辽宁省| 错那县| 康保县| 昂仁县| 卓资县| 从化市| 旅游| 白山市| 安义县| 漯河市| 桂阳县| 临沭县| 凭祥市| 贺兰县| 临猗县| 定兴县| 仪征市| 嫩江县| 衡南县| 广安市| 柳州市| 大足县|