Question

Weird question, but I’m not sure if it’s anti-pattern or not.

Say I have a web app that will be rendering 1000 records to an html table.

The typical approach I’ve seen is to send a query down to the database, translate the records in some way to some abstract state (be it an array, or a object, etc) and place the translated records into a collection that is then iterated over in the view.

As the number of records grows, this approach uses up more and more memory.

Why not send along with the query a callback that performs an operation on each of the translated rows as they are read from the database? This would mean that you don’t need to collect the data for further iteration in the view so the memory footprint shrinks, and you’re not iterating over the data twice.

There must be something implicitly wrong with this approach, because I rarely see it used anywhere. What’s wrong with this approach?

Thanks.

Answer 1

Actually, this is exactly how a well-developed application should behave.

There is nothing wrong with this approach, except that not all database interfaces allow you to do this easily.

If we talk about tabularizing 10 records for a yet another social network, there is no need to mess with callbacks if you can get an array of hashes or whatever with a single call that is already implemented for you.