On 1 wrz 2013, at 05:10, Vitalii Tymchyshyn <tivv00@gmail.com> wrote:
>
>
> Well, there are some more options:
> a) Store int keys and do mapping in the application (e.g. with java enums). This can save you a join, that is
especiallyuseful if you are going to do paged output with limit/offset scenario. Optimizer sometimes produce suboptimal
plansfor join in offset/limit queries.
> b) Store small varchar values as keys (up to "char" type if you really want to save space) and do user display
mappingin application. It's different from (a) since it's harder to mess with the mapping and values are still more or
lessreadable with simple select. But it can be less efficient than (a).
> c) Do mixed approach with mapping table, loaded on start into application memory. This would be an optimization in
caseyou get into optimizer troubles.
>
> Best regards, Vitalii Tymchyshyn
I'd like to leave database in readable form because before I add some new queries and rest endpoints to the
application,I test them as ad-hoc queries using command line. So variant a) isn't good for me. Variant b) is worth
tryingand c) is easy to code, but I still prefer having all this data in database independent of application logic.
Thanks for suggestion,
Lukasz