Я использую приведенную ниже таблицу в нашем случае использования -
create table test_new (
employee_id text,
employee_name text,
value text,
last_modified_date timeuuid,
primary key (employee_id, last_modified_date)
);
create index employee_name_idx on test_new (employee_name);
В приведенной выше таблице employee_id всегда будет уникальным, начиная с 1 и заканчивая 32767. Таким образом, наш шаблон запроса выглядит следующим образом:
- Дайте мне все по любому из employee_id?
- Дайте мне все, что изменилось за последние 5 минут?
- Дайте мне все для любого из employee_name?
Я буду вставлять данные ниже в мою таблицу выше -
insert into test_new (employee_id, employee_name, value, last_modified_date)
values ('1', 'e27', 'some_value', now());
insert into test_new (employee_id, employee_name, value, last_modified_date)
values ('2', 'e27', 'some_new_value', now());
insert into test_new (employee_id, employee_name, value, last_modified_date)
values ('3', 'e28', 'some_new_again_value', now());
Я могу выполнить все мои шаблоны запросов выше, но есть еще одна проблема.
Мой вопрос заключается в том, чтобы избежать этого конкретного сценария для приведенного ниже запроса. Что, если каким-то образом ошибочно попытается выполнить приведенный ниже запрос. Если они это сделают, тогда будет создана другая строка с employee_id равным 1 и с другими полями? Я не хочу, чтобы кто-то снова вставлял один и тот же employee_id, если он уже есть в базе данных Cassandra.
insert into test_new (employee_id, employee_name, value, last_modified_date)
values ('1', 'e29', 'some_new_value', now());
Есть предположения? Я знаю, что это спорная ситуация из-за дебатов по поводу использования СУБД против Cassandra.
А также создание индекса для employee_name вызовет какие-либо проблемы? В моем примере одно и то же имя_сотрудника может иметь несколько идентификаторов_сотрудников, но с разными значениями. Имея в виду, что employee_id
не будет больше, чем 32767
, поэтому максимальное количество строк в приведенной выше таблице будет 32767
.
У меня Кассандра 1.2.9