Database Reference
In-Depth Information
We do, indeed, see
username
and
email
of
bob
, but we also notice something odd:
the
id
column—part of the table's primary key—is
null
! This is because the row with
the
username
value
bob
is essentially a synthetic row, representing the data associated
with a partition key that has no actual rows. To satisfy ourselves of this fact, let's add a
status update for
bob
:
INSERT INTO "users_with_status_updates"
("username", "id", "body")
VALUES ('bob', NOW(), 'Bob status update');
Now, let's take a look at the table again with the help of the
SELECT * FROM
"users_with_status_updates";
statement:
The row with the
id
value
null
has disappeared, since the synthetic construct is no
longer necessary. We now have access to static column values of
bob
via a real row.
Note
For more information about static columns, visit the page in the DataStax CQL reference
Static columns act like predefined joins
Now that we've explored the behavior of static columns, it's rather striking how similar
the data model in
users_with_status_updates
is to the data model represented
by
users
and
user_status_updates
taken together. In particular, both representa-
tions:
• Associate multiple status updates with a single user
• Associate a single email address and password with a single user
• Allow creating and accessing discrete user records, with or without associated
status updates
