Business logic on stored procedure

I am working with stored procedures in order to access my db data.开发者_Python百科 I am trying to put the business logic in the code and not in the stored procedures. But I have a case I don't know how to solve:

I have a table like: Items(item_id, itemd_name, item_price) with 700 items in it.

Now I want to display the client all the items and their names. Since I develop for web, I don't want to load all the 700 items, but using paging - 40 items at a time.

(When I am writing "load" I meen that the stored procedure returns datatable and the code I wrote converts each row to an item class - this is why I don't want to load 700 items, it will proccess many data I don't really need)

So I wrote stored procedure that knows to get 40 items.

Now, I need to summarized all the items prices and add it 16% tax.

The problem is that I can't use the 40 items I get from that store procedure because I need to summarize the price+tax of all the 700 items.

The only solution I found is to use another stored procedure that will return the price+tax sum.

---

Basically you are using two different stored procedures, for two different (albeit connected) business requirements, and that is OK in my book.

The first one is: Display a page of the data with a given offset and page size. The second one is: Display a data summary according to some rules.

Both can be done if you use a simple stored proc that just gets all the data, and you can handle the paging and summarizing on the application side, and that will adhere to your "no logic in the database" rule. This wont be much of a problem when you have 700 rows, however, if that number goes into hundreds of thousands, you will have a large performance penalty for loading and processing tons of items you don't really need.

A second approach is to put the paging logic is one proc, and the summarizing logic in another. The paging logic is pretty generic, so it does not have to be considered "business", but the summary generation, in order to be useful, must incorporate real business logic. This will work, performance wise, but clearly breaks your rule.

Of course, there is no one correct answer, but in most cases, I do not mind putting business logic in the database, because, even the structure of the database is restricted by the business rules of the system. If we want absolutely "no business rules in the database" we should waive default values, check constraints, etc, because they too are business restrictions on the data, those are not properties of the data itself.