Имеется объект в котором хранятся параметры. Он представляет композицию из многих generic полей и коллекций, в том числе вложенных. С этим объектом производятся только операции сохранения и редактирования, т.е. поиск по каким-то отдельным полям и другие операции не требуются. Никаких ограничений на внешние ключи нет. В приложении порядка 100 объектов такого типа.
Возникает вопрос где и как такой объект лучше хранить и как. Подключать документную БД типа mongo ради 100 объектов вроде бы не правильно. Можно делать сериализацию и хранить полученный массив просто как отдельный столбец в БД(rdbms), или конвертировать объект в json (Gson) и опять же хранить просто как столбец в БД. Но тут возникает проблема связанная с тем, что этот класс этих объектов время от времени будет изменяться (могут добавляться новые поля, или могут быть удалены существующие).
Как лучше всего решить такую задачу?
Спасибо.

Garrick, а что будет, если после сохранения класс объекта изменился и нужно по старым данным создать объект измененного класса? Какие возможности есть? В Gson есть аннотация @Since как раз для этой цели, но пока никаких примеров реального использования в таком ключе я не нашел.

mad_nazgul, объект представляет собой большой граф, так что "Создать БД. Довести ее хотя бы до 3 НФ." — это долго и лень.

Petro123,
авторImagine you have an online gaming site, with a database that stores statistics of players in different online games (played in-browser, written in GWT and cross-compiled to javascript). Some of the games are strategic, some are action games, some are platformers. The database is relational and stores players and history of plays and the score.

One day you get an additional requirement: let the players save the game state to the cloud, during the game, so they can restart the game later, at the same point. Needless to say, the only reason to store this temporary state is to return to the game, the state itself will never be introspected.

Now you have two basic choices:

since the games are written in Java, you can quite easily take the model, send it to the server, serialize it in one line of code and store as a blob. The table will be called "saved_games" and it will have foreign keys to the player and so on. From the point of view of the database a "save game" is an opaque, indivisible blob.

you can create a separate relational model for each of your 100 games (this will be tens of tables per game). For pacman alone, for example, you will have to have a table storing positions of all the uneaten pellets, bonuses, positions and current state of ghosts. If someone, someday, modifies the game, even slightly, you will have to update the relational model. Also, for each type of game, you will have to implement a logic to write the Java model to the database, and to read it back.

The answer by Justin Cave says, that you should go with the second option. I think this would be a huge mistake.

mad_nazgul, как я понял, я должен сам реализовать SAX?

Petro123, этот как пример просто. Но суть такая же. Есть большой объект, который маппить в БД нет смысла.

mad_nazgul, например




Какой Ваш вариант реляционной модели для такого объекта класса A?

mayton, я пока ничего не пробовал. Но если после сохранения класс чуть поменять, с десериализацией не возникнет проблем(всякие serialId и прочее)?

Petro123, классы есть, хранятся в памяти.
Не совсем понял Вашу мысль.

mayton, Можете меня еще кратко просветить по поводу SAX, DOM, JAXB, JDOM, Jaksonы и прочее. Это все работает в оба конца? Т.е. и Object to XML и XML to Object? Т.е. могу я сам описать программно логику трансляции объекта в XML?

mad_nazgul, не могу найти пример, в котором описывается как используя SAX конвертировать объект в XML.

mad_nazgul, т.е. меня больше интересует как из объекта сделать XML, какие для этого варианты существуют кроме DOM и JAXB.

Blazkowicz, JAXB это всегда работа аннотациями? При изменении класса с добавлением новых полей с аннотациями и попыткой создать объект из ранее сохраненного XML все сломается?

mayton,
maytonНо этот вариант лучше попробовать после Serializable

XML нагляднее. Можно контролировать что и как конвертировалось и сразу понять правильно или нет.

Сохранять полученное значений (сериализация или XML/Json) в blob/text столбце БД нормально?

mad_nazgul, так мне индексация и поиск не нужны.

mayton, все намного банальнее. Я спрашиваю, как это сохранять xml как простую строку в поле text базы данных типа Mysql.
Т.е. либо так не надо делать и надо хранить небольшое количество xml только в отдельных файлах, или такая практика хранить xml в текстовом поле вполне нормальная.
Мне не нужна поддержка каких либо запросов, как json/xml api в Oracle.

И еще. Я вот никак не могу понять, для чего используется Apache Jackrabbit

Blazkowicz, XADisk двухфазные

Кстати, а что насчет protocol buffers? В интернете много тем protocol buffers vs serialization.
Я попробовал использовать простой механизм сериализации для своей задачи, но столкнулся с огромным количеством проблем (конструкторы, финальные поля, статические поля)