33 lines
1.6 KiB
SQL
33 lines
1.6 KiB
SQL
-- Migration: Create user_blocked_emails table
|
|
-- Purpose: Store blocked email addresses for each user to prevent unwanted sharing
|
|
--
|
|
-- Rationale for this Cassandra Table Structure:
|
|
-- This table is designed around the primary query: "Fetch all email addresses blocked by a specific user."
|
|
|
|
CREATE TABLE IF NOT EXISTS user_blocked_emails (
|
|
-- PARTITION KEY: This is the first component of the primary key. It determines
|
|
-- data distribution across the cluster. All data for a single user_id will reside
|
|
-- on the same node (and its replicas), making lookups by user_id very fast.
|
|
user_id UUID,
|
|
|
|
-- CLUSTERING KEY: This determines the on-disk sorting order of rows within a
|
|
-- partition. For a given user, blocked emails will be stored sorted alphabetically.
|
|
-- This allows for efficient retrieval of sorted data and enables range queries on the email.
|
|
blocked_email TEXT,
|
|
|
|
-- Data columns associated with the block action.
|
|
blocked_user_id UUID,
|
|
reason TEXT,
|
|
created_at TIMESTAMP,
|
|
|
|
-- The PRIMARY KEY defines how data is stored and retrieved.
|
|
-- The first element (`user_id`) is the Partition Key.
|
|
-- Subsequent elements (`blocked_email`) are Clustering Keys.
|
|
-- The combination of all primary key columns uniquely identifies a row, meaning a
|
|
-- user can block a specific email only once.
|
|
PRIMARY KEY (user_id, blocked_email)
|
|
)
|
|
-- This clause specifies the on-disk sorting order for the clustering key(s).
|
|
-- In this case, blocked emails within each user's partition will be sorted in
|
|
-- ascending alphabetical order, which is efficient for display.
|
|
WITH CLUSTERING ORDER BY (blocked_email ASC);
|