Database Reference
In-Depth Information
So, for an unnamed index on the
users
table on the
browsing_history
column,
you would use the following query:
DROP INDEX IF EXISTS users_browsing_history_idx;
Creating a data type
Cassandra gives you freedom to compose your own data type using the basic types that
Cassandra provides you with. Much like
Struct
in C, it gives you relief in cases where
you have to denormalize data because Cassandra does not support the
join
queries. The
most common example of this is putting multiple shipping addresses in a map within a
users' table. In RDBMS, you would probably just create two tables:
users
and
ad-
dresses
. You'd make
user_id
a foreign key in the
addresses
table. Then, you use
a
join
query to retrieve a
User
object that has
Map<String, Address>
that lists
all the shipping address of the user. In Cassandra, we have two options to go about it. The
first option is to create a custom data type, which is
User Defined Type
(
UDT
), for the
address
object, and save it as a part of row in the
users
table. This is denormalization
using UDT.
The other option is to have a separate
addresses
table and store the primary keys of
these addresses in the
users
table. When retrieving, the former just needs to fetch the
data from the
users
table to get a user's data along with its addresses. In the latter case,
however, you will need to pull the user's records and then use the primary keys of the ad-
dresses to execute another
IN
query on the
addresses
table to get addresses. It's a lot
of work. We would go with the former, the custom data type with the denormalization ap-
proach.
Creating a type has the same syntax as creating a table without properties. Here's the
query pattern:
CREATE TYPE [ IF NOT EXISTS ] type_name
( field_name field_type [, field_name field_type, ... ] );
Let's take a look at the following example:
# Create a UDT
CREATE TYPE address ( address text, country varchar,
postal_code varchar, preference int );
