БД документов по дизайну приложений

Возможно, JPA и eclipseLink были бы моим выбором.

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

В вашем случае нужны очень сильные инструменты: контроль версий, отдельный промежуточный сервер, управляемая логика, отчетность (автоматическое документирование модели и взаимодействий).

JPA в принципе может сама создавать таблицы базы данных из сущностей (или наоборот). Итак, это один слой. Он поддерживает метамодель.

Исходя из вашей метамодели, вам действительно нужно сделать что-то умное.

Самым простым и достижимым было бы остаться только с вашей метамоделью и определить управление версиями и так далее. Ручной код будет использовать общие данные, такие как Карта. Вы также можете хранить код в базе данных, управлять его версиями и использовать Java Scripting API. Но вам нужно будет сообщить о расширении руководству и убедиться в его осуществимости — создать прототип.

Я определенно надеюсь, что кто-то знает лучшее решение.

P.S.

Возможно, база данных NoSQL была бы чем-то вроде базы данных документов.

Трудно дать хороший совет с таким небольшим количеством информации. Однако вы включили тег «JCR», и похоже, что ваш вариант использования похож на систему управления контентом или документами, поэтому вам определенно следует рассмотреть JCR. См. "Когда использовать JCR вместо других вариантов?" для более общего ответа, но я попытаюсь описать его преимущества для вашего конкретного случая использования. (Однако всегда выбирайте лучший инструмент для работы.)

Возможно, лучшая функция JCR для вас — это возможность иметь гибкую схему, которая позволяет добавлять (или изменять) метаданные для разных документов и с течением времени. Вы можете либо ограничить свойства, чтобы ваши приложения добавляли только принятую информацию, либо вы можете быть немного свободнее и оставить свои параметры открытыми, чтобы добавлять дополнительные метаданные по мере необходимости. Вы даже можете разбить свои метаданные на «характеристики», которые можно добавить к отдельным узлам с помощью миксинов. Короче говоря, JCR дает вам массу гибкости при проектировании вашей структуры данных, а также дает вам несколько ручек для контроля того, насколько принудительно/гибко вы используете.

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

В-третьих, многие репозитории JCR даже поддерживают запросы к содержимому репозитория (путем сопоставления типов узлов с реляционными табличными структурами). JCR 2.0 имеет несколько языков, в том числе XPath и SQL-подобный язык под названием «JCR-SQL2».

Есть несколько библиотек отображения объектов для JCR, но они, скорее всего, будут мешать реальному использованию гибкости структуры данных JCR. JCR сам по себе является API Java и имеет встроенную поддержку событий, безопасности, запросов, блокировки, управления версиями и т. д.

Если вы посмотрите на JCR, обязательно ознакомьтесь с различными реализациями, включая Jackrabbit и ModeShape. Каждый из них предлагает что-то свое (например, Jackrabbit является эталонной реализацией, а ModeShape предлагает некоторые расширения и дополнительные функции, такие как расширенные языки запросов и последовательность; см. это связанный вопрос).