When to use a calculated attribute

Clearly calculated attributes place a strain on an apps performance, so all I hear is not to use them. I'm wondering if there ever is a valid usecase when a calculated attribute should be used? Or would it be better to just remove the option from the Mendix platform altogether?    
3 answers

And do not forget one of the most important use case: if you need to translate data that is in the database. Because then you need to retrieve the correct value based on the language of the user. So in multi lingual apps you almost always need this functionality.




Here an example for translating data.

This is a civil state table

As one can see the desciption can be translated to different languages. And the calculated field uses this microflow:




Nice debate; 

When calculated options might be an option;

  1. When read action of value is smaller then actions which affects the value.
  2. When consumed dataset size is limited.
  3. When updates affecting the value is in many locations of your app (read complex to cover all).


Knowing that calculated attributes are calculated per object/attribute using a microflow above must be VERY VERY VERY clear and supersedes the impact of calculating the value and storing them each time an update is done.

My experience is; all 3 above are rare and resulting of this I never used a calculated attribute the last 11,5 years working with Mendix.

BUT; removing them; no. I would rather see that Mendix introduced Database procedures which moves the calculation from runtime to database. Solving the negative impact of calculation in a microflow.



Very curious to all other opinions in the mx community





I have a valid use case (I think): we have a consumed REST service where we get objects (not a lot) with a date as an integer/long. We map it to a non-persistable object and use a calculated attribute to have it also available as a datetime attribute. We could do the conversion in the mapping itself, obviously, but we need the integer/long notation too.

When it comes to persistable tables I agree use cases are rare. But when you’d need event flows on one or more very large and frequently updated associated tables to write some value to a much smaller and less used table, it may be better to use a calculated attribute on that smaller table instead. Still, I’ll always do my best to avoid it.