2013-03-14 1 views
10

Мое приложение часто должно украшать значения в документах, которые он обслуживает, используя поиск, чтобы извлекать человекообразные формы различных кодов.Каков наиболее эффективный способ хранения пар имя/значение в базе данных 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, но в этом случае похоже, что это приведет к очень большому числу очень маленьких файлов. Это то, о чем я должен беспокоиться?

ответ

8

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

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

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

6

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

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

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