Rules vs stored values, and when a Jedox rule quietly kills your cube
· Jedox
Jedox rules calculate on the fly, which is powerful but carries a cost that grows with the model. Here is how I decide between an on-read rule and a stored value.
One of the first big decisions in any Jedox model is how a number actually gets there: is it calculated live by a rule, or is it loaded and stored in the cube? Both are right in different places, and getting the choice wrong is one of the most common reasons a model feels slow.
What a rule actually does
A Jedox rule calculates on read. The value is not stored anywhere; the engine works it out every time the cell is requested. That is the whole trade. You gain a number that is always current and costs no storage, and you pay for it with compute on every single read.
Where rules fit well
- Ratios and percentages (margin percent, growth percent), which must never be summed up a hierarchy.
- Currency conversion and allocations.
- Anything that has to reflect the latest inputs with no recalculation step.
- Cross-cube lookups.
Because the result is always live and takes no space, rules keep the model lean and correct. For this kind of logic, a rule is exactly the right tool.
Where rules hurt
The cost lands on every read. A rule that spans a large area, references wide ranges, or depends on other rules (a rule reading a cell that is itself calculated by a rule) multiplies the work the engine does for one query. Open a big report built on heavy, chained rules and you feel it immediately.
How I keep rules fast
- Keep the rule area tight. Define the smallest target area that does the job and do not let a rule apply to cells it has no business touching.
- Use markers so the engine knows the dependency path and recalculates only what changed.
- Avoid deep rule chains. If rule C reads rule B reads rule A, every read walks the whole chain.
- Do not rule what consolidation already does. Simple roll-ups up a hierarchy are handled by the aggregation engine and are fast, so you rarely need a rule to sum children.
When to store instead
Load or precalculate a value when:
- the calculation is heavy and multi-step over large dimensions,
- the result feeds many other calculations repeatedly, or
- you need a frozen snapshot or a version that should not move when inputs change.
Stored values read instantly. The trade-off is storage, a refresh step, and the risk of going stale if you forget to rerun it.
A simple rule of thumb
Calculate live when the number is light, must be current, or should not aggregate. Store when the number is expensive, reused heavily, or is a deliberate snapshot. When in doubt, build it as a rule first for correctness, then measure. If a real report is slow, that is the moment to move the heavy part to a stored value.
The mistake I see most often is treating rules as free. They are not. You are trading storage for compute on every read, so spend that compute where it buys you freshness and store the rest.