Best practices - Simple mapping table
Application Type
Traditional Web, Mobile, Reactive, Service

Hi there,

within a service, we are receiving data mainly in short "code" identifiers. In order to display these, we need to map a number of fields code->displayText , each field having its own mapping table, which have alphanumeric codes and about 2-30 entries, so not much data.


"PPN" -> "Passport"

"CZ" -> "Citizen Card"

"HC" -> "Health Card Number"

"NI" -> "National unique individual identifier "

I am looking for advice how to best aproach it. Looking at standard entities would require a DB call per field, which seems overkill, especially with this little variance. 

I am struggling with Static entities, as I don't seem to be able to look up a Record by string.

Wrapping this into some custom-populated lists, case statements or object makes the mapping table content very intransparent. As the reference data might change over time, it would be important to review it....

Am I missing an obvious trick? In PHP, I would approach this using associative arrays and simply accessing the alphanumeric key...

Thanks a lot!


Hi Jan,

can't offer you any best practices, but my first idea would be that this should somehow be part of your data model, it is representing concepts in your system, so it feels wrong to just hide them away in some list building action.  But that's just me, I would put my own mother in a datamodel if I could.

And choice between entity or static entity would depend in the first place on whether I'm willing to redeploy the module every time one of the codes or display values needs to get changed / added / deleted, and in the second place, if I need to do a lot of coding against the codes (like validations and such), that just looks better with static entities. 

And of course, if you don't model them as part of your data but hardcode them in some action, that also means redeploying for changed values.

It sounds like you think only entities go into the database, but static entities also do, so that's no reason to choose the one over the other.

What are your concerns about the DB call per entity being overkill ?  I don't know enough about what your actually doing to understand this.  You are talking about a service, is this running on server side ?  When you say 'receiving data' what does that mean, where are you receiving them from ?  And when are you displaying this data, is this at same time like receiving them or at some later point, if so, how and where do you store them between receiving and displaying ?  

So let's say you call some api exposed by another system that gives you codes, and for displaying the api result you want to translate them to a display value, that's the only scenario where I can see reluctance to go to your database just to read the mapping, is it something like that?

In other scenarios, as soon as you store in and retrieve from your database, I can't see it matter for performance to do an extra read into the mapping table.

But even if you have to do a database call only and just to retrieve the mapping, I wouldn't try to solve a performance problem that doesn't exist yet, Outsystems platform does some built-in caching (probably even more so for static entities than normal entities I would imagine, but I'm not sure) and you could always build your own caching mechanisms on top of that, when and if needed.

As to easily using the mapping when it comes from a static entity, you could use the code as id instead of an autonumber, and then get the display value like so :



Hi Dorine,

thanks a lot for your extensive advice. My scenario actually is exactly the one you are describing: reading data from a service with codes in the payload and mapping just for display purposes. But you do have a point about potentially over-optimizing an element that doesn't have an issue (yet).

I may end up moving the entire logic (receiving and mapping data) into a service module which would run server-side anyway. 

I will continue to experiment with entities and static entities and hopefully I will be able to comment on a "good practice" way in the end.

Thanks again for your support!


Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.