Although we’ve tackled and expressed scd - there are some limitations with this approach. It is tempting to treat everything as a slowly changing dimension - particularly as you denormalise table. For example, one could model the products which a customer is holding as a denoramlised slowly changing dimension table - however this can be a really bad idea!
Why is that?
Simply put, the aggregations over SCD make it untentable in the context of trying to manage custom aggregations or requests! What solution is there instead?
Perhaps the easiest solution is simply don’t do it. The value of SCD is completely lost when trying to combine it with something event driven in this nature. One way could be to record an event on the annivesary of the product; that way it is still captured in some kind of time based fashion as a feature. This is typically used in the sense of customer products when the product in question has an annual or regular renewal cycle.
The other mode of thinking is to compose the data in a such a way that functional programming approaches such as monoids can take care of the time difference aspects - in this way we limit the types of custom aggregation to a set which can be managed; we’ll leave this as a discussion at another stage.