Хранение двумерной таблицы (таблицы решений) в XML для эффективного запроса (-ов)

Question

Мне нужно реализовать таблицу маршрутизации, в которой есть несколько параметров.

Например, я указываю пять атрибутов во входящем сообщении ниже

Customer Txn Group Txn Type Sender Priority  Target
UTI       CORP     ONEOFF   ABC    LOW       TRG1
UTI       GOV      ONEOFF   ABC    LOW       TRG2

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

Я хочу сохранить эти данные в XML и, используя Java, загружать их в память, а когда приходит сообщение, я хочу определить цель на основе атрибутов.

Цените любые входные данные.

Спасибо, Manglu

Answer 1

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

<table>
 <record Customer="UTI" Txn-Group="CORP" 
      Txn-Type="ONEOFF" Sender="ABC1" 
      Priority="LOW"  Target="TRG1"/>

 <record Customer="UTI" Txn-Group="Gov" 
      Txn-Type="ONEOFF" Sender="ABC2" 
      Priority="LOW"  Target="TRG2"/>


</table>

Существует чрезвычайно эффективный способ запроса данных в этом формате с использованием инструкции <xsl:key> и клавиши XSLT () function :

Это преобразование :

<xsl:stylesheet version="1.0"
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:output omit-xml-declaration="yes"/>

 <xsl:key name="kRec" match="record"
  use="concat(@Customer,'+',@Sender)"/>

    <xsl:template match="/">
      <xsl:copy-of select="key('kRec', 'UTI+ABC2')"/>
    </xsl:template>
</xsl:stylesheet>

при применении к вышеуказанному XML-документу дает желаемый результат :

<record Customer="UTI" 
        Txn-Group="Gov" Txn-Type="ONEOFF" 
        Sender="ABC2" Priority="LOW" 
        Target="TRG2"/>

Обратите внимание на следующее :

1. Может быть несколько <xsl:key>, определенных , которые идентифицируют запись с использованием различных комбинаций значений, которые должны объединяться вместе (что бы ни считалось "ключами" и / или "первичными ключами") .

2. Если для использования конкатенации «первичных ключей» определено <xsl:key>, то при оценке функции key () будет найдена уникальная запись (или ее нет).

3. Если для использования конкатенации "неосновных ключей " определено <xsl:key>, то при оценке функции key () может быть найдено более одной записи.

4. Инструкция <xsl:key> является эквивалентом определения индекса в базе данных . Это делает использование функции key () чрезвычайно эффективным .

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

Answer 2

Если вы загружаете его в память, на самом деле не имеет значения, какую форму принимает XML - я бы посоветовал облегчить чтение или запись вручную. Когда вы загружаете его в память, , а затем , вы должны преобразовать его в соответствующую структуру данных. (Точный характер структуры данных будет зависеть от точного характера требований.)

РЕДАКТИРОВАТЬ: Это противостоять аргументам, высказанным Димитром в комментариях:

Я не уверен, что вы подумали, что я предлагал, чтобы люди внедрили свою собственную хэш-таблицу - я точно не был. Просто сохраните прямую хеш-таблицу или, возможно, MultiMap для каждого столбца, который вы хотите использовать в качестве ключа. Разработчики знают, как использовать хеш-таблицы.

Что касается эффективности времени выполнения, которая, по вашему мнению, будет более эффективной:

• Вы создаете некоторый XSLT (и имейте в виду, что является чужой территорией, по крайней мере, относительно говоря, для большинства разработчиков)
• XSLT-движок анализирует его. Этого шага можно избежать, если вы используете библиотеку XSLT, которая позволяет просто параметризовать существующий запрос. Тем не менее, у вас есть некоторая дополнительная работа.
• Движок XSLT обращается к хеш-таблицам (по крайней мере, вы надеетесь) и возвращает узел
• Вы конвертируете узел в более полезную структуру данных

Или:

• Вы просматриваете соответствующие записи в своей хеш-таблице на основе заданных вами ключей, переходя прямо к полезной структуре данных

Думаю, я бы лично доверял второму. Использование XSLT здесь похоже на использование отвертки для нанесения ударов по гвоздю ...

Answer 3

Да, ваша основная проблема в том, что вы используете "XML" и "эффективность" в одном предложении.

Редактировать: Нет, серьезно, ты убиваешь меня. Тот факт, что несколько человек в этой теме используют «высокоэффективный» для описания всего, что нужно , для операций с форматом данных, которые требуют анализа строк только для того, чтобы выяснить, где находятся ваши поля, показывает, что несколько человек в этой теме даже не знаю, что означает слово «эффективный». Откажись от меня столько, сколько захочешь сказать. Я могу взять это, тренер.

Answer 4

Я согласен с предыдущими двумя постерами - вам определенно не следует сохранять внутреннее представление этих данных в XML при запросах при поступлении сообщений.

Представление XML может быть чем угодно, вы можете сделать что-то вроде этого:

<routes>
  <route customer="UTI" txn-group="CORP" txn-type="ONEOFF" .../>
  ...
  </routes>

Мое внутреннее представление будет зависеть от формата входящего сообщения и языка. Простым представлением может быть карта, отображающая структуру данных (т. Е. Ключевые поля, из которых принимается решение о маршрутизации) с информацией о целевом маршруте.

В зависимости от ваших требований к производительности, вы можете хранить ключевую / целевую информацию в виде строк, хотя в любой высокопроизводительной системе вам, вероятно, захочется выполнить прямое сравнение памяти (в C / C ++) или некоторое целочисленное сравнение в форме. 1008 *

Answer 5

Это зависит от того, что повторяется, а что может быть пустым. XML не известен своей эффективной возможностью запроса, поскольку он не является ни фиксированной длиной, ни компактным.