Logic in the Data Layer

I was just listening to a conversation between two developers. One of
them said, "there should be *no logic* in the stored procedure or the
DAO..." [emphasis mine]

I hear this a lot, and I think it's wrong because it is too broad. I
agree that there should be no *business* logic in those places, but we
have to be clear about the difference between business logic, a.k.a,
business rules, and other kinds of rules or logic.

In the conversation I just heard, the logic being discussed was not a
business rule, it was a rule about how data gets stored, and what
happens in the database when a particular operation occurs. This is
data logic, and it is perfectly proper for it to be in a stored
procedure or DAO.

In general, any logic or rules that relate specifically to the data
itself -- how it is stored, where it is stored, how it is aggregated
and moved -- is data logic, and belongs to the data layer. After all,
what does my application really care about how the data gets stored,
retrieved or deleted? And remember, logical relationships between
entities are not business rules.

I admit that the line can sometimes get blurry, but let us not make
such foolish blanket statements such as "no logic of any kind here."