The way I see it, when building dynamic charts with filters, each time the user requests filtered data I can
Execute a new MySQL query, and use MySQL to do the filtering.
SELECT date,
SUM(IF( `column` = `condition`, 1, 0)) as count
...
Execute a new MySQL query, and use the server-side language (PHP in my case) to filter.
function getData(condition) {
$resultSet = mysqli_query($link, "SELECT date, column ... ");
$count = 0;
while ($row = mysqli_fetch_assoc($result_set)) {
if ($row['column'] == 'condition') {
$count++;
}
}
}
Initially execute a single MySQL query, pass all the data to the client, and use Javascript & d3 to do the filtering.
I expect the answer is not black-and-white. For instance, if some filter is barely requested, it may not make sense to make the other 95% of users wait for the relevant data, and thus the filter would necessitate a new data call. But I'm really thinking about edge cases - situations where filters are used regularly, but idiosyncratically. At times like this, is it better to put filtering logic in front-end, back-end, or within my database queries?
Generally, if the filtering can be done on the front end, it should be done there. The advantages are:
The disadvantages are that it may be slower and more complicated than it would be on the backend. However, dependent on data volume, there's a lot of cases (like your examples) where Javascript is plenty good enough. d3 even has a built-in filter function:
//remove anything that isn't cake
d3.selectAll('whatever')
.filter(function(d){return d.type != 'cake'})
.remove()
If you need more complex filtering, such as basic aggregates, you can use Crossfilter (also from Mike Bostock) or the excellent d3+crossfilter wrapper dc.js.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With