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:
When calculated options might be an option;
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.