Home/ Questions/Q 8600417
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-12T01:36:45+00:00

We need to store aggregated values for different accounts which summarise various numbers on

  • 0

We need to store aggregated values for different accounts which summarise various numbers on Month/Year basis. These numbers would be updated each time the data is updated (usually once or twice every 24 hours).

I’m expecting the data to be the results of PIVOT functions e.g.:

Year    Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2011    0   0   0   0   0   0   95  33  34  24  36  52

Each account will need different aggregates e.g. “Count Of Customers”, “Count Of Orders” and “Value Of Sales” and I’m not sure whether it would be best to add a key to the data or use separate tables e.g.:

Year    Key        Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2011    CntOrders  0   0   0   0   0   0   95  33  34  24  36  52
2011    CntCust    0   0   0   0   0   0   95  33  34  24  36  52
2011    ValOrders  0   0   0   0   0   0   95  33  34  24  36  52

Or
dbo.CountOfOrders

Year    Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2011    0   0   0   0   0   0   95  33  34  24  36  52

dbo.ValueOfOrders

Year    Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2011    0   0   0   0   0   0   95  33  34  24  36  52

I’ve read a number of posts suggesting both NoSQL and SQL Server so I’m not sure which way we should go or how to decide.

We can’t justify a dedicated cube at the moment but I’m wondering if it would be better to store the values in a NoSQL database or whether we should stick with SQL Server?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I’ll stick with SQL. However, if you are worried about the time to rebuild such PIVOT table, don’t, because you don’t have to necessarily build a table with unique “key”.

    Build it with key + process datetime and just append it to the main pivot. So during creation of the incrementals it will be bounded by your transaction timestamp (begin and end). There should be much bloat. If there is, you can collapse the process dates in a weekend job.

    • 0