@nicklightbody had the good idea of delving deeper into concepts and implementation strategies that enable high-performance solutions.
I am opening a separate thread for the calculation field topic, but consider @nicklightbody as the OP.
We all started out making extensive use of (unstored) calculation fields because they come in handy and we get a quick result. And we all made the experience that what works well for a couple or even a few hundred records, will not necessarily perform well with large data sets - specially when relationships are involved.
I admit to still using them in solutions with larger data sets, but not the way I did when starting developing in FM. Today, I am using them for displaying up-to-date data on layouts and there only for the parent table and/or a few related records in portals. A good example is a date/days calculation that involves current date or time.
They are not used for generating reports on larger data sets, as this surely slows things down to a crawl.
So (unstored) calculations can be useful and be used as long as we are aware of what the limits of application are.
How do you take advantage of (unstored) calculation fields?