Каков наиболее эффективный способ хранения пар имя/значение в базе данных Marklogic?

Моему приложению часто приходится украшать значения в документах, которые оно обслуживает, используя поиск для извлечения удобочитаемых форм различных кодов.

Например, <product_code>PC001</product_code> хотелось бы вернуть как <product_code code='PC001'>Widgets</product_code>. Это не всегда product_code; есть несколько различных типов кода, которые требуют одинакового поведения (некоторые из них имеют всего несколько десятков примеров, некоторые — несколько тысяч).

Что я хочу знать, так это то, как наиболее эффективно хранить эти данные в базе данных? Я могу думать о двух возможностях:

1) Один документ для каждого типа кода со многими элементами:

<product-codes>
  <product-code code = "PC001">Widgets</product-code>
  <product-code code = "PC002">Wodgets</product-code>
  <product-code code = "PC003">Wudgets</product-code>
</product-codes>

2) Один документ на код, каждый из которых содержит элемент <product-code>, как указано выше.

(Очевидно, что оба варианта будут включать разумные индексы)

Является ли один из них заметно быстрее, чем другой? Есть ли другой, лучший вариант?

Мне кажется, что обычно лучше хранить одну «вещь» для каждого документа, поскольку она концептуально немного чище и (я понимаю) лучше подходит для индексации ML, но в этом случае кажется, что это приведет к очень большому количеству очень маленьких файлов. . Это то, о чем я должен беспокоиться?


xml marklogic xquery
person Will Goring    schedule 14.03.2013    source источник

Ответы (2)


arrow_upward
8
arrow_downward

Все, что нужно искать самостоятельно, должно быть отдельным документом или фрагментом. Однако, если вы просто выполняете поиск, индекс диапазона атрибутов элемента должен очень быстро возвращать значения:

element-attribute-range-query(xs:QName('product-code'), xs:QName('code'), '=', 'PC001') 
=> 
Widgets

При использовании индекса диапазона все поиски будут происходить из одного и того же индекса независимо от того, как вы разбиваете документы. Поэтому, если вам не нужно будет использовать cts:search для product-code для извлечения фактических элементов, не имеет значения, как вы разбиваете документы.

person wst    schedule 14.03.2013

arrow_upward
7
arrow_downward

Другой подход заключается в хранении карты, представляющей пары "имя-значение".

let $m := map:map()
let $_ := map:put($m, 'a', 'fubar')
return document { $m }

Это возвращает XML-представление хэш-карты, которое можно сохранить непосредственно в базе данных с помощью xdmp:document-insert. Вы можете превратить XML-карту обратно в собственную карту, используя map:map в качестве функции-конструктора. Нативную карту также можно запомнить с помощью xdmp:set-server-field.

person mblakele    schedule 14.03.2013