Java data structure to use with Hibernate to store unknown number of parameters?

Question

Following problem: I want to render a news stream of short messages based on localized texts. In various places of these messages I have to insert parameters to "customize" them. I guess you know what I mean ;)

My question probably falls into the "Which is the best style to do it?" category: How would you store these parameters (they may be Strings and Numbers that need to be formatted according to Locale) in the database? I'm using Hibernate to do the ORM and I can think of the following solutions:

• build a combined String and save it as such (ugly and hard to maintain I think)
• do some kind of fancy normalization and and make every parameter a single row on the database (clean I guess, but a performance nightmare)
• Put the params into an Array, Map or other Java data structure and save it in binary format (probably causes a lot of overhead size-wise)

I tend towards option #3 but I'm afraid that it might be to costly in terms of size in the database. What do you think?

Answer 1

directly put it as string and save it ..

Answer 2

If you can afford the performance hit of using the normalized approach of having a separate table I would go with this approach. We use the same approach as your first suggestion at work, and it gets messy, especially when you reach the column limit and key/values start getting truncated!

Answer 3

Do the normalization. I would suggest something like:

Table Message id

Table Params message_id key value

Storing serialized Java objects in the database is quite a bad thing in most cases. As they are hard to maintain and you cannot access them with 'simple' SQL tools.

The performance impact is not as big, as you can fetch all together in a single select using a join.

Answer 4

It depends a bit. Is the number of parameters huge for each entity? If it is not probable second option is the best.

If you don't want to add extra queries caused by the lazy load you can always change fetch type for the variable number of parameters that would only add one join to a query you were always doing. In normal conditions it is not a big price to pay.

Also the third and the first one forbids forever any type of queries over the parameters. A huge technical debt for the future I would not be willing to pay.