Much like the post before, you are confusing business logic with integrity. I agree on the notion of garbage in garbage out, however who are you to decide what is garbage. You can't. The business rules decide what information is important from day to day and those business rule change on the whim of a customer or CEO or News conference or just about anything else the current industrial climate may provide.

As for the set of data, I don't think anyone would argue that getting a set of data out of the database belongs anywhere else. It is what you do with that data that matters. One day you might do something as simple as sorting the data, then next you may have to use the data set in a complex mathmatical formula for derivite trading. You can't do the latter in the database so the data that is in the database shouldn't be specific to that action. Get the set you need and manipulate it programmatically.

As for the comment on overhead, all of those things are cheap and if your application and business logic live in the correct place, then scaling is easy. Take a portion and run here and a portion and run there. You can scale to the hardware available and you have many options for handling network overhead. You can do none of that with you logic living in the database.

Again, in a small scope with limited data, your approach works well. None of these things are issues in a small shop setting.