Calculated Fields Documentation

[seberly]

I haven't found any formal documentation on the wiki about calculated fields. Could someone please direct me to an article that I missing or are the plans to create an article for this?

Thanks,
Scott

[CapaJC]

There probably isn't much doc because calculated fields are evil. Copied from another post:

"Calculated fields are calculated every time a row is read. This means any calculation that does complex processing is re-run on every row read. In an example with 100 rows, that means a calculated field, even one which isn't displayed on your list, is calculated once per row or 100 times per list. Often you can get the same results, and better performance by using an Insert/Update business rule to set a field value, rather than relying on a calculated field."

Case in point: me. 6 years ago I created a calculated field in /hi on cmdb_ci_service to help me troubleshoot something. It didn't even do a GlideRecord query, it simply dotwalked to a field from a related table. When I was done troubleshooting, I forgot to delete the field. A year ago, while looking into a /hi performance issue, I discovered that this unused, forgotten calculated field was responsible for 90 PERCENT of the SQL "Select" statements in our CMDB.

If you can possibly populate this field with a Business Rule that runs before insert/update, you'll thank yourself later down the road.

[seberly]

Thanks for you input! I'll take that into consideration.

[apjohn2]

Dude you probably just saved me a ton of time and heartache here. Thank you. I would hit helpful like 10 times if I could.

[Brunno Santos]

@CapaJC 

9 years later... 😂

Do you still maintain your position about calculated fields? 🤣

An what about calculated fields that only rely on other fields from the same record... Is it that bad too?