I need to dynamically update weekly and monthly sales data per product and customer. These need to be updated and checked during the sale of a product, and for various reasons I’m not able to use stored procedures or materialized views for this (I’ll read everything into the application, modify everything in memory and then update and commit the results).
What is the best table structure for holding the sales during a period?
- Store the period type (M, W) with start and end dates, or just the type and start date?
- Use date fields and a char, or code it into a string (‘M201201’ / ‘W201248’)
- Normalize sales and periods into two tables, or keep both sales and the period in a single table?
I will be doing two kinds of queries – select the sales of the current weekly (xor monthly) period/customer/article but not update them, and select for update weekly and monthly periods for a customer/article.
If you store both the start and end dates of the applicable period in the row, then your retrieval queries will be much easier, at least the ones that are based on a single date (like today). This is a very typical mode of access since you are probably going to be looking at things from the perspective of a business transaction (like a specific sale) which happens on a given date.
It is very direct and simple to say
where @date_of_interest >= start_date and @date_of_interest <= end_date. Any other combination requires you to do date arithmetic either in code before you go to your query or within your query itself.Keeping a type code (M, W) as well as both start and end dates entails introducing some redundancy. However, you might choose to introduce this redundancy for the sake of easing data retrieval. This:
where @date_of_interest >= start_date and @date_of_interest <= end_date and range_type='M'is also very direct and simple.As with all denormalization, you need to ensure that you have controls that will manage this redundancy.