I'm actually arguing against this, but want to see if I'm out of line.
We have a PaymentQueue table and a simple UI. This table is, at the moment, primarily used by the UI and no other business logic. The UI requires data that is only in a subset of possible statuses.
One developer put this status restriction in the SPROC itself. I'm arguing to put it into the website UI layer, since it's view dependent.
The benefit if his approach is it returns less data over the wire, but messes up other processes that may, in the future, utilize this SP, since it now always restricts to certain types. The benefit of my approach is it keeps view logic out of the database, but pulls across more data on the wire (I plan to narrow by date range to minimize this).
My thought was to introduce a flag in the SPROC that, if enabled, would filter by these types, thus allowing the SPROC to be more flexible for either case.
What is the best approach? Thanks.