2

NOTE: This is not an "opinion-based" question. I am asking a technical question about how the platform handles queries and memory. Please do not flag it.

I want to display survey results using Visualforce charting, and all results come from the same dataset. The available values for each question are picklists in the survey, but are stored as text because they could change. (Example: What country do you live in? - Might have some values added in the future by marketing, but I don't want to update Salesforce every time they do that)

I'm debating using Visualforce components for the charts, and can easily pull the fields to show and the order by using a Field Set and iterating over that.

Here's my question:

Should I do a monolithic query of as many as 40 fields and about 300 records, and pass them all to each component, to be iterated over for displaying the count of each value...

OR

Should I pass into each component the field name, and then do a query in each component, iterating over that to get the counts of each value?

I'm worried that passing the entire query result into each component will use a lot of memory, but I also don't want to do unnecessary queries that may slow page load time.

3
  • 3
    How is your component built? Does it accept a field set or single field?
    – Jayant Das
    Commented Oct 16, 2018 at 18:36
  • 4
    You're only interested in aggregate results, right? Not the individual records?
    – sfdcfox
    Commented Oct 16, 2018 at 18:50
  • Charting is for showing aggregate results, passing fields and records is bit confusing... are you trying to create a chart/graph/some graphical representatio of data or you want tabular data? Commented Oct 16, 2018 at 19:19

1 Answer 1

2

Presuming you're only interested in the aggregate results, and not the individual records, you can use 25 queries using the GROUP BY syntax. This converts the need to process individual records at the Apex code level. This uses more queries but drastically reduces CPU/heap usage in exchange. As long as you don't expect to exceed the 100 SOQL queries or 2000 query rows per GROUP BY query, this design will offer optimal performance.

1
  • Thanks. I'm conservatively looking at never more than 40 queries and no more than 500 rows in the entire set. So I'll build it with individual queries to avoid all those loops. Thanks! Commented Oct 16, 2018 at 19:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .