• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Best no-SQL database strategy to display aggregated graph data?

fuzzybabybunny

Moderator<br>Digital & Video Cameras
Moderator
I'm helping a friend create an internal questionnaire that a company will use to test its own CSRs.

Secret testers will call or email a certain CSR and fill out a 40-question questionnaire.

The company has 5 regions worldwide and many CSRs.

In the end they want to see graph data that compares (at least) the total scores of all 5 regions over a year, divided by month.

So I'm thinking that over 5 years or so, there could be something like 500+ individual documents in the Tests collection.

Each document/test would have a:

totalScore
maxPossibleScore
regionId
dateCreated
csrId

What's the best practice to query for and aggregate all that data into an object so that it can be displayed on something like Highcharts?

http://www.highcharts.com/demo/bar-basic

Say that I'm displaying a chart showing all scores for all regions in the year 2014.

On the page load, I can query for all tests that have a dateCreated of 2014 and return the totalScore, maxPossibleScore, regionId. That will give me back an array of objects and I can loop through that to get the info necessary to display the chart.

BUT would querying through 500+ individual documents and bring back all this data be really time-consuming?
 
The amount of data you are asking for is minute in terms of query time

It would seem best to have a few linked tables
  • First table: Keyed by region ID and CSR ID
  • Second table: keyed by CSR ID and containing the other info with a link to the survey document data
  • third table: keyed by CSR ID and linked back to the Second table.

Returning all the information would not be a big hit (500 records total); but also is all the extra data needed. Poor design/planning and if it grows; then you could have a problem.

I think your estimate of # of records will be way off.
5 years is only 100 surveys/year
20 per region
2 surveys per month in each region. Now look at the average # of CSRs. Such will not provide useful information on seeing trends for a given CSR
 
Last edited:
Back
Top