Type 2 Dimension for a fact measure

Question

I have a need to store products along with their prices and quantities (and many other things) and track the history.

Now, given both price and quantity are stored as integers, it is my understanding these are fact measures. So we might have a table like:

f_products:
  id
  sku 
  price
  quantity

As the price varies over time we can insert a new fact, and I can introduce effective dates to the table to allow for querying the price or quantity at a given time.

But with this design, it means if the quantity changes, I must insert another row, repeating the unchanged price value again. And while this isn't too bad for 2 columns, I have in fact 10.

So, my design is:

f_products:
  id
  sku 

price:
   id
   product_id
   price
   start_date
   end_date

another "dimension":
   id
   product_id
   value
   start_date
   end_date

and so on

Now the "fact" no longer needs to change when the price changes, and I can query for historical values across these tables.

So my question is, this doesn't seem to fit the standard fact / dimension designs, so I wonder how more experienced modellers would approach these requirements.

Answer 1

Honestly it really just depends on your use cases, but for me I would likely just store all 10 columns in the same table and call it a day (unless they were very unrelated to each other, then I might normalize it a bit). Having the full list of fields might influence different answers, and your approach is a valid one as well. It just might be more work to maintain that way.

Essentially it would be a Transaction table, and log a record for each change on any of the fields. Then it's easiest to look at what the current state of a given product is, or what its state was for a given timeframe.

Yea you'll run into some data duplication, but most modern database systems automatically compress their tables anyway. So unless you think you're going to be creating billions of transactions a day and start creeping into big data territory, I wouldn't be super concerned from a performance perspective.