DAL versus BLL

Also, business logic methods from an application can be mapped to the Data Access Layer. So, for example, instead of making a query into a database to fetch all users from several tables the application can call a single method from a DAL which abstracts those database calls.

http://en.wikipedia.org/wiki/Data_access_layer

We'll start with creating a software architecture composed of a Data Access Layer (DAL) using Typed DataSets, a Business Logic Layer (BLL) that enforces custom business rules, and a presentation layer

http://msdn.microsoft.com/en-us/library/aa581778.aspx

The application logic [BLL] orchestrates the DAL, domain classes and services to pursue the expected behavior. The application logic communicates with the presentation layer through view model objects and communicates with the DAL through domain objects. The DAL, in turn, references the model and the ORM assembly.

 http://msdn.microsoft.com/en-us/magazine/hh456393.aspx

Databases are designed to be very fast and efficient with CRUD operations. They are not designed to format telephone numbers, calculate optimum usage and peak periods of utility usage, determine geographic destinations and routings of shipments, and so on. Yet, I have seen all of these cases, and even more complex ones implemented mostly or even wholly inside stored procedures. ... Which tables are affected is business logic as well. The database should not have any knowledge of which tables constitute a customer on the business level. ... But stored procedures should not do anything other than join data when returning data. For updating data it should do exactly and only that and should not interpret the data in any way.

http://www.codeproject.com/Articles/10746/Dude-where-s-my-business-logic