Разработка / Использование пользовательской таблицы в Cassandra для создания учетной записи и входа в систему

Cassandra использует подход к моделированию на основе запросов, поэтому вы можете иметь одинаковые избыточные денормализованные данные в отдельных таблицах … и это нормально. Вы будете хотеть держать это в уме, продвигаясь вперед.

Регистрация и вход в систему на самом деле две разные вещи, так что вы захотите разделить их. Думая о запросах и шаблонах доступа в долгосрочной перспективе, вероятно, имеет смысл отделить данные учетной записи пользователя от учетных данных, поскольку учетные данные могут измениться.

CREATE TABLE users (
userid uuid,
firstname text,
lastname text,
email text,
created_date timestamp,
PRIMARY KEY (userid)
);

CREATE TABLE usercredentials (
email text,
password text,
userid uuid,
PRIMARY KEY (email)
);

Таким образом, когда пользователь меняет свой пароль, он не влияет на общий users Таблица. Кроме того, частота, с которой большинство пользователей изменяют свои электронные письма, случайное удаление (и, следовательно, сгенерированная надгробная плита), не должна быть такой большой проблемой. Это не позволит SELECT * FROM usercredentials WHERE email=? AND password=? запрос на работу, так что вам придется SELECT password FROM usercredentials WHERE email=? вместо этого, но это исключает возможность зависания старых паролей и возникновения потенциальных проблем. Вы могли бы поспорить разделение на email и кластеризация на password, но это на самом деле не имеет смысла, так как электронное письмо никогда не будет иметь более одного пароля за раз (хотя вы можете создать дополнительную таблицу, подобную этой, для хранения истории паролей).

Чтобы отслеживать логины, я бы посоветовал что-то вроде этого:

CREATE TABLE logins (
time timestamp,
userid uuid,
email text,
PRIMARY KEY (userid, time)
);

Это приведет к тому, что ваши строки будут обозначены комбинацией userid а также time, Разница здесь в том, что userid является ключом раздела, поэтому все логины для каждого пользователя будут храниться вместе. time действует как ключ кластеризации, чтобы вы могли выполнять ORDER BY операции на нем. email здесь есть поле полезной нагрузки, которое имеет смысл, потому что вы можете видеть его, а также легко группировать логины для пользователя, который мог изменить свой адрес электронной почты. Это должно охватывать основные таблицы.

Для стороны кодирования CodeIgniter-PHPCassa Проект может помочь вам.