Skip to main content
Solved

Material - Location vs Separate dimensions

  • Sep 29, 2026 7:23 AM UTC
  • 2 replies
  • 73 views
Apprentice Author
Forum|alt.badge.img+2

Hi everyone,

I’m looking for some advice on the best architecture for a DRP model.

We have around 100k Products and 11 DCs. I’m considering two options:

  1. A single Product-DC dimension containing only valid combinations.
  2. Keeping Product and DC as separate dimensions and calculating at their intersection.

My initial assumption was that Pigment’s sparse engine would make the two approaches fairly similar from a calculation-density perspective. However, I’m wondering whether the higher cardinality of the Product × DC intersection could have a significant impact, especially since the DRP logic uses PREVIOUSOF().

Would you recommend one approach over the other in this case? And are there any specific performance considerations I should take into account?

 

Many thanks ! 

Best answer by Nathan

Hi,

Crossing Product and DC does not create more cardinality as Pigment is managing sparsity.

It’s the same number of data points, it will have no impact on PREVIOUSOF()

 

View original

      2 replies

      Nathan
      Employee
      Forum|alt.badge.img+12
      • NathanEmployee
      • Employee
      • Answer
      • Sep 29, 2026 8:33 AM UTC

      Hi,

      Crossing Product and DC does not create more cardinality as Pigment is managing sparsity.

      It’s the same number of data points, it will have no impact on PREVIOUSOF()

       

        New Here

        To add to Nathan’s point on sparsity, I’d lean towards keeping Product and DC as separate dimensions for reasons beyond performance. Separate dimensions let you aggregate naturally by DC or up the product hierarchy, reuse the same Product list across demand, supply and finance blocks, and use BY/REMOVE modifiers cleanly. A combined Product-DC dimension locks you into one grain and you end up re-deriving Product and DC as properties anyway. If you need to restrict calculations to valid combinations, a boolean “Valid Product x DC” metric used as a scope filter in your formulas does that without changing the dimensionality. The one place a combined list earns its keep is as a transaction list for combination-level attributes like lead time or MOQ per product-DC pair, feeding the two-dimension metrics via lookups.

        Ask your question here!

        Terms & ConditionsAccessibility statement