create table users_by_id_name(
id int,
createdOn bigint, -- timestamp in millisec
name text,
age int,
primary key (id,name,createdOn)
)WITH CLUSTERING ORDER BY (name DESC, createdOn DESC);
Использовать над таблицей определение, чтобы ввести пользователей. Вставить запрос -
insert into users_by_id_name (id,createdOn,name,age) values (1,100,'darthvedar',28);
обновить пользователя, вставить строку снова с таким же идентификатором пользователя и обновленным именем и значением createdOn.
insert into users_by_id_name (id,createdOn,name,age) values (1,200,'obi-wan-kenobi',28);
при выборе использования пользовательского запроса ниже -
Выбор по идентификатор пользователя -
select * from users_by_id_name where id=1 limit 1;
Выбор пользователя по имени -
select * from users_by_id_name where name='obi-wan-kenobi' ALLOW FILTERING;
Другой способ заключается в использовании вторичного индекс имени пользователя. Подумайте, имя пользователя не будет меняться слишком часто, поэтому вторичный индекс также является одним из хороших вариантов.
Edit после комментариев -
Если у вас есть очень частые обновления по имени пользователя, было бы лучше использовать две различные таблицы.
create table users_by_id(
id int,
name text,
age int,
primary key (id)
);
create table users_by_name(
id int,
name text,
age int,
primary key (name)
);
При вставке вставляйте обе таблицы с использованием оператор партии.
Надеюсь, это поможет.
«чтобы обновить пользователя, вставьте строку снова с тем же идентификатором пользователя и обновленным именем и созданным значением». - Вы вставляете новую комбинацию первичных ключей. Это создаст новую запись в таблице. Он не будет обновлять существующую запись. Это будет проблема, когда вы хотите получить все все записи. Спасибо за ответ. – Sree
Да, вот почему мы используем ограничение 1 в нашем запросе, так что он займет последнюю запись. – Gunwant
Я не думаю, что это хороший подход, когда у вас есть миллионы записей и их обновление, что создаст кучи нежелательных данных. – Sree