design patterns - Business logic on stored procedure -

i working stored procedures in order access db data. trying put business logic in code , not in stored procedures. have case don't know how solve:

i have table like: items(item_id, itemd_name, item_price) 700 items in it.

now want display client items , names. since develop web, don't want load 700 items, using paging - 40 items @ time.

(when writing "load" meen stored procedure returns datatable , code wrote converts each row item class - why don't want load 700 items, proccess many data don't need)

so wrote stored procedure knows 40 items.

now, need summarized items prices , add 16% tax.

the problem can't use 40 items store procedure because need summarize price+tax of 700 items.

the solution found use stored procedure return price+tax sum.

basically using 2 different stored procedures, 2 different (albeit connected) business requirements, , ok in book.

the first 1 is: display page of data given offset , page size. second 1 is: display data summary according rules.

both can done if use simple stored proc gets data, , can handle paging , summarizing on application side, , adhere "no logic in database" rule. wont of problem when have 700 rows, however, if number goes hundreds of thousands, have large performance penalty loading , processing tons of items don't need.

a second approach put paging logic 1 proc, , summarizing logic in another. paging logic pretty generic, not have considered "business", summary generation, in order useful, must incorporate real business logic. work, performance wise, breaks rule.

of course, there no 1 correct answer, in cases, not mind putting business logic in database, because, structure of database restricted business rules of system. if want absolutely "no business rules in database" should waive default values, check constraints, etc, because business restrictions on data, not properties of data itself.