Таким образом, каждый документ моей коллекции содержит пять различных полей, а именно:
mode
type
category
price
size
Я хочу, чтобы мои пользователи фильтровали документы на основе вышеуказанных полей, то есть пользователь может фильтровать результаты, пытаясь использовать любую комбинацию полейвозможно как:
mode=='foo' && type=='bar'
category=='foo' && price>500 && size<50
category=='bar'
...
...
это приведет к многочисленным различным комбинационным возможностям.Однако для полей mode
, category
и type
пользователь может фильтровать только на основе условия равенства , тогда как для полей price
и size
он может фильтровать, используя сравнения диапазонов .
Более того, мне также нужна функциональность для orderBy
, использующая цену как в восходящем, так и в убывающем порядке.
Таким образом, для любого примененного фильтра запрос в базе данных может содержать до 3 предложений равенства и более2 сравнения диапазона.Это, очевидно, означает, что я должен создать соответствующие составные индексы в консоли Firebase для запроса данных таким образом.
Вот некоторые примеры запросов:
db.where('price', '<', 2000).where('category','==','foo').where('size', '>', 80).orderBy('price', 'desc')
db.where('price', '>', 300).where('type','==','foo').where('mode', '==', 'bar').where('category', '==', 'foo').where('size', '<', 500).orderBy('price')
Поскольку это приведет к довольно большому количеству индексов, которые будут стоить места для хранения, документация Firebase предлагает объединение индексов для предложений равенства
Теперь мой вопросКаков наилучший способ создания составных индексов для ситуации, описанной выше, чтобы я мог запрашивать данные, используя любую комбинацию, как описано выше, при создании наименьшего количества индексов в консоли, используя преимущества «техники слияния» в firestore.
Мне было интересно, нужно ли мне создавать индексы примерно так:
mode (ascending), price (ascending)
type (ascending), price (ascending)
category (ascending), price (ascending)
size (ascending), price (ascending)
mode (ascending), price (descending)
type (ascending), price (descending)
category (ascending), price (descending)
size (ascending), price (descending)
Проблема здесь тестирует, так как очень беспокойно тестировать каждый и всезапрос возможен для созданных индексов.Поэтому я искал комбинацию индексов, которая гарантирует весь возможный набор запросов, описанных выше.