Имеется объект в котором хранятся параметры. Он представляет композицию из многих 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?