Хотя я знаю, что указывать идентификаторы, зависящие от вашей базы данных, не рекомендуется и, по-видимому, этого легко избежать с помощью классических реляционных баз данных, мне интересно, как избежать влияния на производительность при работе с базой данных nosql, где следует избегать и усложнять поисковые индексы (длинные) составные ключи не должны предоставляться на конечных точках.
Например, в Cassandra доступные запросы связаны со схемой базы данных, поэтому без добавления индексов, как реализовать API, которые работают с такими объектами и, следовательно, их соответствующие (оченьдлинные составные) идентификаторы?
Например, как можно реализовать API REST для проверки существования записи в таблице, которая может выглядеть следующим образом:
TABLE A (
...,
PRIMARY KEY ((pk1, pk2), ck1, ck2, ck3, ck4, ck5)
)
Соответствующая конечная точка будет выглядетькак это (или, по крайней мере, где-то содержать все компоненты первичного ключа в URL)
GET /v1/A/pk1/pk2/ck1/ck2/ck3/ck4/ck5
Это выглядит сложно, и если запрос списка элементов быстро приведет к очень длинным URL.
Как эта проблема решается ссоюзник?