> sometimes they're just wrong
or it could be throw-away code that wasn't thrown away after all (bad code lives forever)
that example will become unwieldy fast when you have many accounts and you fetch the whole table into memory;
I've seen things, terrible things:
* "let's fetch the whole product list and pick 5 random products in code to show as `related`" (this was a magento site, ended up doing like 5000 queries per product page, they were asking me why is the database so slow - the database was taking it like a champ, incidentally, but it was like 1ms away on a different server)
* "let's store all objects we fetch from the db in memcache and fetch them one by one to generate some graphs because latency is zero" - they're still not able to have memcached on a different server, or to have 2 application servers 5 years later...
* many, many django bulk processing scripts contining "for thing in Thing.objects.all()" - Python database drivers tend to load the whole result set in memory; if your table is like 1-2 GB you may get away with it, when it's 100GB, not so much; postgres drivers are especially terrible at this
* note written in all caps in some php configuration file saying something along the lines of "do not delete this, it's a function written by X, we don't know why it only works here and it's 2 days to black fucking friday" - that commit was 3 years old
I've had my share of clever queries that had the db server grinding for 30 minutes, but I learned to be careful about these things pretty early on; some people never seem to learn, tho.