XML и деревья объектов

Question

В моем текущем проекте (система управления заказами с нуля) мы обрабатываем заказы в виде объектов XML, которые сохраняются в реляционной базе данных.

Я хотел бы изложить требования, как это:

• Выбор различных деталей из любого места в порядке
• Обновление/обогащения данных (например, из системы CRM)
• Сохранение записи из изменения (аннулирование старых данных, вставка новых значений)
• Детали заказов должны быть легко доступны по SQL-запросам (для поддержки второго уровня)

Что мы сделали:

• Сериализация производится с фирменным кодом, разборке заказ в таблицы, как customer, address, phone_number, order_position и т.д.
• Всякий раз, когда заказ будет обработан немного дальше (например из-за входящего события), он полностью считывается из базы данных и собирается обратно в XML-документ.
• Выбор данных выполняется XPath (разбросанный по коду).
• Большинство обновлений выполняется непосредственно в базе данных (заказ будет перезагружен для следующего шага).

проблемы мы сталкиваемся:

• Структура заказа (XSD) развивается с каждым выпуском. Поэтому XPaths и пользовательская настойчивость часто ломаются и производят ошибки.
• Мы закончили тем, что имеем дело с документом и базой данных (поскольку уровень сохранения не может сохранить изменения в документе).

Производительность на самом деле не является проблемой (пока), так как это автономная система, и заказы часто преднамеренно задерживаются на несколько дней.

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

Что вы считаете правильным решением для решения этих требований? Будет ли работать с графиком объекта, что-то вроде JXPath и OGNL, а также с помощью OL-преобразователя - лучший подход? Или с использованием поддержки XML, например. база данных Oracle?

Answer 1

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

Вместо этого используйте определение декларативной схемы для проверки изменений и доступа к данным. Рассмотрите заказ как единую систему координат, выраженную как XML-документ. Используйте документ-ориентированный магазин, такой как MongoDB, Cassandra или одну из многих баз данных XML, чтобы напрямую манипулировать документом. Не беспокойтесь, разрезав его на куски, чтобы сохранить его в реляционном db.

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

Answer 2

Стандартный подход Java EE предназначен для представления ваших данных как POJO и использования JPA для доступа к базе данных и JAXB для преобразования объектов в/из XML.

JPA

• объекта к Relational стандартной
• Поддерживается всеми поставщиками серверных приложений.
• несколько доступных реализаций EclipseLink, Hibernate и т.д.
• Мощный язык запросов JPQL (который очень похож на SQL)
• Ручки оптимизации запросов для вас.

JAXB

• объектов к XML стандарта
• Поддерживается всеми поставщиками серверов приложений.
• несколько реализаций доступны: EclipseLink MOXy, Metro, Apache JaxMe и т.д.

Пример

• http://bdoughan.blogspot.com/2010/08/creating-restful-web-service-part-15.html