#marklogic #marklogic-8
#marklogic #marklogic-8
Вопрос:
Требование:
-
Решайте напрямую через Index, не хотите открывать документы (следовательно, не рассматривая выражение FLOWR).
-
Результаты поиска возвращают список документов заказа на поставку
-
Заказ на поставку может содержать или не содержать строку (для целей примера)
- В заказе на поставку могут быть тысячи позиций, каждая из которых имеет свой тип
- Для типа будет только 1 строка (без дубликатов в заказе на покупку)
- Для сортировки: На основе одного из многих типов, выбранных пользователем во время поиска (иногда стул, иногда лампа и т.д.) Порядок сортировки на основе количества только для этого конкретного типа (например: стул)
Пример документа 1:
<purchase-order>
<line-items>
<line-item type="lamp" amount="3500"></line-item>
<line-item type="couch" amount="50000"></line-item>
<line-item type="chair" amount="40000"></line-item>
</line-items>
<other-stuff></other-stuff>
</purchase-order>
Sample document 2:
<purchase-order>
<line-items>
<line-item type="couch" amount="10000"> </line-item>
<line-item type="chair" amount="80000"></line-item>
</line-items>
<other-stuff></other-stuff>
</purchase-order>
Ожидаемая последовательность результатов:
- Запрос на сортировку документа по количеству desc для типа chair должен возвращать последовательность документов 2 и 1
- Запрос на сортировку документа по количеству desc для типа couch должен возвращать последовательность документов 1 и 2
Комментарии:
1. Вероятно, вам потребуется создать индекс пути для каждого из типов, например
line-item[@type = "couch"]/@amount
, и определить для этого отдельный порядок сортировки. Используете ли вы MarkLogic REST-api?2. @ grtjn , мы не используем MarkLogic REST-api, но вместо этого search:search api через XQUERY У нас будут тысячи (предположим, максимум 3k) типов. Потребует ли это определения индексов пути до 3 тыс. Можете ли вы также уточнить, что вы имели в виду, говоря «определить отдельный порядок сортировки»
3. @grtjn, Что способствовало бы потреблению памяти для индекса пути определенного типа (например, «couch»), любых документов с: Надеемся, что нет потребления памяти для документов, имеющих только через d ниже: a) / заказ на покупку b) / заказ на покупку / позиции c) / заказ на покупку/позиции/ line-item d) / заказ на покупку / позиции / line-item[@type of anykind] т. е. «стул», надеясь на потребление памяти только для: e) /заказа на покупку/ позиций/line-item[@type = «диван»]
4. Проблема заключалась бы в том, что потребление памяти для индекса пути определенного типа было бы увеличено из-за документов, не имеющих определенного типа для этого индекса.
5. Да, 3k индексов пути. Каждый из них будет включать только документы с совпадениями, поэтому никаких mem для несоответствий.